CD Actual 1

home *** CD-ROM | disk | FTP | other *** search

/ CD Actual 1 / PC Actual CD 01.iso / f1 / cimb.arj / TECNICO.TXT < prev next >

Wrap

Text File | 1994-10-19 | 142.1 KB | 3,745 lines

CONVERSOR DE IMAGENES DE MAPAS DE BITS PROYECTO FIN DE CARRERA DIPLOMATURA EN INFORMATICA FACULTAD DE INFORMATICA Y ESTADISTICA UNIVERSIDAD DE SEVILLA ANTONIO LADESA JURADO, 1994 TUTOR: GABRIEL JIMENEZ MORENO INDICE GENERAL PARTE I MANUAL TECNICO DEL PROGRAMA INDICE 1 INTRODUCCION. 2 OBJETIVOS. 3 EL SISTEMA Y LOS RECURSOS EMPLEADOS. 3.1 HARDWARE. 3.1.1 LA PANTALLA GRAFICA. 3.1.2 LA GESTION DE LA MEMORIA. 3.1.3 EL INTERFACE CON EL USUARIO. 3.1.4 IMPRESION. 3.2 SOFTWARE. 3.2.1 HERRAMIENTAS DE DESARROLLO. 3.2.2 PROGRAMAS DE UTILIDAD. 3.3 LIMITACIONES Y POSIBLES AMPLIACIONES. 3.3.1 LIMITACIONES. 3.3.2 POSIBLES AMPLIACIONES. 4 ESTRUCTURA GENERAL DE LA APLICACION. FLUJO DE DATOS. 5 ESTRUCTURA DE LOS FICHEROS. FORMATOS GRAFICOS. 5.1 EL FORMATO TIFF (Tagged Image File Format) 5.2 EL FORMATO PCX (PC PAINTBRUSH) 5.3 EL FORMATO MAC (MACPAINT) 5.4 EL FORMATO IMG/GEM 5.5 EL FORMATO BMP (WINDOWS) 5.6 EL FORMATO TGA (TARGA) 5.7 EL FORMATO GIF (Graphics Interchange Format) 6 ESTRUCTURAS DE DATOS. REPRESENTACION DE LAS IMAGENES. 6.1 LA ESTRUCTURA DE DATOS. 6.2 REPRESENTACION DE LAS IMAGENES. 6.2.1 SEGUN EL TIPO DE MEMORIA. 6.2.1.1 MEMORIA EMS. 6.2.1.2 MEMORIA XMS. 6.2.1.3 MEMORIA VMS. 6.2.2 SEGUN EL MODO DE VISUALIZACION. 6.2.2.1 MODO MONOCROMO. 6.2.2.2 MODO EGA. 6.2.2.3 MODO VGA. 7 EL TRATAMIENTO DE LAS IMAGENES. 7.1 CONVERSION DE FORMATOS. 7.1.1 CARGA DE IMAGENES. 7.1.2 VISUALIZACION DE IMAGENES. 7.1.3 GRABACION DE IMAGENES. 7.2 TRANSFORMACION DE IMAGENES. 7.2.1 ESCALADO DE IMAGENES. 7.2.2 REFLEJO DE IMAGENES. 7.2.3 CONVERSION A GRIS Y A BLANCO Y NEGRO. 7.2.3.1 REDUCCION A TONOS DE GRIS. 7.2.3.2 APROXIMACION AL DITHERING. METODO BAYER. 7.2.3.3 DIFUSION DE ERRORES. ALGORITMOS. 7.2.4 OBTENCION DE NEGATIVOS. 7.2.5 ESCALADO DEL NUMERO DE COLORES. 7.3 IMPRESION DE IMAGENES. 7.3.1 LA IMPRESORA EPSON FX-80. 7.3.2 IMPRESORA POSTSCRIPT. APENDICE A. LISTA NUMERICA DE TAGS. TIFF Versión 5.0 BIBLIOGRAFIA 1 INTRODUCCION. Sin duda alguna, una de las disciplinas que más auge ha adquirido en los últimos años en lo que a informática se refiere es la representación gráfica por ordenador. A ello ha contribuido de manera determinante el vertiginoso desarrollo del hardware, especialmente de los ordenadores personales. Los costes y tiempos de procesamiento se han reducido mientras que las capacidades de memoria y almacenamiento han aumentado. Esto ha propiciado la irrupción del mundo de la imagen en la ciencia informática. Las aplicaciones gráficas son variadísimas: Autoedición, CAD, presentaciones, retoque fotográfico, post-producción de vídeo, animación, simulación, realidad virtual. Todo ello aderezado con la nueva aportación de la técnica al mundo informático: La multimedia. El impulso del tratamiento gráfico por ordenador ha dado lugar a la necesidad de unificar criterios a la hora de almacenar, intercambiar y representar los gráficos. Así surgen los formatos gráficos. Las aplicaciones almacenan sus datos del modo más adecuado para su posterior tratamiento. Así, los programas de CAD almacenan sus datos mediante primitivas de dibujo mientras que las aplicaciones de tratamiento fotográfico usan mapas de bits. Existen estándares gráficos para todas las aplicaciones posibles. Sin embargo no es posible unificar los formatos propios de cada tipo de aplicación en uno solo, de ahí la necesidad de desarrollar programas conversores entre los formatos gráficos.2 OBJETIVOS. Esta obra se propone acercar al usuario informático los métodos para la conversión entre formatos gráficos de mapas de bits (bitmaps). Se define un gráfico de mapa de bits como una sucesión de bits que definen un conjunto de puntos de color con los que se constituye una imagen. Estos puntos de color reciben el nombre de pixels. Los pixels se constituyen como la unidad visual más pequeña de una imagen. El estudio de los gráficos de mapas de bits comprende el conocimiento de las técnicas de codificación, compresión, visualización e impresión de las imágenes, así como de otras técnicas auxiliares de transformación como pueden ser el escalado o conversión de imágenes en color a blanco y negro. Por otro lado se hace imprescindible dar a conocer cómo se usan los elementos físicos de la máquina para permitir la puesta en práctica de las técnicas discutidas teóricamente. Finalmente, el dominio de los conceptos relacionados con los gráficos de mapas de bits permitirá la inclusión y manipulación de éstos en las aplicaciones que el lector pueda desarrollar o la conversión de formatos no estándares en otros de uso generalizado. No es objeto de este estudio el competir con los potentes programas comerciales de tratamiento de imágenes que también poseen la habilidad de importar y exportar gráficos bitmap en distintos formatos, sino desvelar los secretos que gobiernan el tránsito de las imágenes entre el disco, la memoria y la pantalla.3 EL SISTEMA Y LOS RECURSOS EMPLEADOS. El proyecto ha sido desarrollado para su ejecución en ordenadores personales. Esto es posible gracias al gran avance tecnológico que estos sistemas han experimentado en pocos años. Cuando IBM comercializó el primer PC (Personal Computer) a principios de los 80, era impensable que este tipo de máquinas pudieran, en tan corto período de tiempo, permitir la ejecución de aplicaciones gráficas hasta ese momento sólo reservadas para equipos de gran capacidad. En este capítulo se van a tratar, por un lado, los elementos físicos (hardware) y por otro, los programas (software) requeridos para la implementación del proyecto. 3.1 HARDWARE. Los ordenadores de tipo PC compatible son aquellos equipados con un microprocesador ix86 de INTEL. Esta familia de microprocesadores mantiene la compatibilidad entre los procesadores de versiones anteriores, con lo que los futuros procesadores pueden ejecutar las aplicaciones de sus predecesores. La evolución sufrida en 15 años por este tipo de máquinas es espectacular. De 4,77 a 100 Megahercios de velocidad y de 8 a 32 bits de palabra, con lo que esto supone de incremento en la memoria direccionable. Conviene mencionar además el incremento en la capacidad y rapidez de los periféricos usados con estos procesadores. La aplicación ha sido desarrollada para ser ejecutada en cualquiera de éstos procesadores. El equipo debe procesador 8086 o superior. 3.1.1 LA PANTALLA GRAFICA. El adaptador o tarjeta de gráficos instalado en un microordenador determina la capacidad máxima de un sistema a la hora de la representación de las imágenes. Esta capacidad para representar las imágenes viene definida por dos aspectos: Pixels y colores. Se define un pixel como el elemento visual más pequeño que puede ser controlado por el software en la pantalla. Un pixel está compuesto generalmente por la mezcla de los colores rojo, verde y azul (sistema RGB). La intensidad de cada uno de los tres colores primarios proporciona al pixel la tonalidad de éste en la pantalla. Así pues la capacidad máxima de un adaptador de gráficos, también llamada resolución, viene determinada por el número máximo de pixels y de colores simultáneos que pueden visualizarse en la pantalla. Existen varios estándares de adaptadores gráficos que ofrecen distintos modos de operación, cada uno de ellos caracterizado por una determinada resolución. Los adaptadores más conocidos son: CGA, MCGA, EGA, VGA y SVGA, ordenados por su capacidad de menor a mayor. Las resoluciones de cada uno de ellos oscilan entre los 320x200 pixels con 4 colores de la CGA hasta los 1280x1024 de 16 millones de colores (True Color o color real) de las más potentes tarjetas SVGA. Los adaptadores de gráficos difieren en el modo de organizar la memoria de pantalla y en la visualización de dicha memoria en el monitor[15]. La CGA usa una memoria de pantalla conocida como multibit por pixel, mientras que en las EGA y VGA utilizan memoria de pantalla multiplano por pixel. El sistema multiplano por pixel consiste en almacenar en la memoria de pantalla cuatro imágenes gráficas distintas. Cada imagen se denomina plano de bits. Cada plano de bits almacena la imagen completa de uno de los cuatro colores primarios utilizados: rojo, verde, azul y nivel de intensidad. El controlador de pantalla lee simultáneamente los bits correspondientes a los cuatro planos de bits, y los utiliza para determinar el color. Dado que cada plano de bits puede tener un valor 0 o 1 para cada pixel, la unión de los 4 bits (1 por plano) permite una variación de 0000 a 1111 en binario, lo que implica 16 posibles combinaciones. El color asociado a cada combinación es determinado por el hardware del controlador gráfico. En tarjetas EGA, que usan un sistema digital, el hardware dibuja en pantalla cada punto rojo, verde y azul, con una intensidad que puede ser nula, media o alta. En las VGA, que usan un sistema analógico, el hardware dibuja cada punto rojo, verde y azul, con una intensidad que puede variar desde 0 a un máximo. La mezcla visual de estos tríos de rojo verde y azul en la pantalla es lo que produce la aparente variación de tonalidades en el monitor. En el sistema multibit por pixel, se usa un solo plano, llamado mapa de bits. Cada pixel se representa en el mapa de bits con un determinado número de bits. En el modo CGA 320x200 de 4 colores, se necesitan dos bits por pixel, ya que dos bits pueden representar cuatro colores distintos: 00, 01, 10 y 11. Para el modo 640x200 de 2 colores se requiere un bit por pixel. Esta variedad en el modo de almacenamiento de las imágenes en la memoria de pantalla también ha sido adoptada por los formatos gráficos, con objeto de simplificar el software para la representación de las imágenes. En este estudio aparecen formatos que usan las dos técnicas. El programa ha sido desarrollado para trabajar sobre una tarjeta VGA. La elección no ha sido caprichosa. La tarjeta VGA se ha constituido como la controladora de vídeo más estándar y soporta todos los modos gráficos de sus antecesoras. Los modos EGA 640x480 de 16 colores (válido también para imágenes monocromas) y VGA 320x200 de 256 colores son los usados en la aplicación que soporta el tratamiento de imágenes de hasta 256 colores. El tamaño de las imágenes no constituye ningún problema ya que el módulo visualizador del programa permite 'mover' la pantalla sobre la imagen (panning). Las funciones para la visualización de las imágenes se encuentran en el módulo VIDEO.3.1.2 LA GESTION DE LA MEMORIA. Uno de los principales aspectos a tener en cuenta a la hora de desarrollar una aplicación es el estudio de la memoria del sistema, con objeto de aprovecharla al máximo. Al estudiar la memoria de los PCs, se pone de manifiesto la importante limitación del sistema operativo DOS en este aspecto. El DOS está diseñado para utilizar 1024kb de memoria, de los cuales sólo 640kb están disponibles para el usuario. Esta limitación viene dada porque el DOS fue diseñado en principio para los procesadores 8086 y 8088 de Intel, que solo eran capaces de direccionar 1Mb de memoria. En la actualidad, los PCs equipados con procesadores superiores permiten sobrepasar ampliamente este límite. Los tipos de memoria de un PC son los siguientes: - MEMORIA CONVENCIONAL Se llama memoria convencional a la memoria entre 0 y 640Kb. Todos los ordenadores disponen de ella. En esta memoria se almacena el sistema operativo, los controladores de dispositivo que aparecen en el fichero de configuración (CONFIG.SYS) y en el de arranque (AUTOEXEC.BAT), los programas residentes (TSR) y los de aplicación. - MEMORIA SUPERIOR El área de memoria superior es la zona de memoria situada entre los 640Kb y 1024Kb. En ella se encuentran, por ejemplo, los datos del hardware (tarjeta gráfica, monitor). Una parte de esta memoria, no utilizada por el sistema, la constituyen los bloques de memoria superior (UMB), que se pueden usar para almacenar controladores de dispositivo, liberando así memoria convencional para ejecutar aplicaciones. - MEMORIA EXTENDIDA A la memoria que comienza más allá de 1Mb se la conoce como memoria extendida. Este tipo de memoria (denominada también XMS) sólo está disponible en equipos dotados con microprocesador 80286 o superior. En equipos 386 y 486 se podría llegar hasta 4096Mb. Estos microprocesadores tienen dos modos de funcionamiento: - Modo real, emulando al 8086. La memoria XMS se usa para guardar datos, para lo que se requiere instalar un controlador (driver) de memoria extendida, como el HIMEM.SYS suministrado por el DOS. - Modo protegido, aprovechando todas sus características. Se usa para guardar datos y programas. - MEMORIA EXPANDIDA Se conoce también con el nombre de memoria EMS y fue diseñada por Lotus/Intel/Microsoft. Una ventaja sobre la memoria XMS es que funciona en cualquier microprocesador, por contra, el acceso a esta memoria es más lento. En principio esta memoria consistía en una tarjeta de expansión que se utilizaba por medio de un driver. Actualmente, en ordenadores 386 y 486 es posible emular estas tarjetas a partir de la memoria extendida. En cualquiera de los dos casos es necesario instalar un controlador en el fichero de configuración como el EMM386.EXE suministrado con el DOS. Solo pueden acceder a esta memoria las aplicaciones preparadas para ello. Estos programas acceden a ella por medio de una zona llamada marco de página (page frame) localizada en la memoria superior. La memoria expandida está dividida en bancos o bloques de 16Kb cada uno. En el marco de página se pueden situar 4 bancos de memoria. Cuando un programa de aplicación necesita datos que no están en las direcciones apuntadas por los bancos situados en el marco de página, se produce el mapeado entre páginas lógicas (las del marco de página) y páginas físicas (las de la memoria expandida), con lo que se consigue el acceso a las páginas de memoria deseadas. - AREA DE MEMORIA BAJA La zona de memoria baja está formada por los primeros 64Kb de la memoria convencional. En ella se carga normalmente el sistema operativo, los controladores de dispositivo, la tabla de interrupciones y el área de datos del DOS. - AREA DE MEMORIA ALTA La zona de memoria alta (HMA) está formada por los primeros 64Kb de la memoria extendida. No se utiliza normalmente por los programas, por lo que se suele cargar en ella una parte del sistema operativo. - MEMORIA VIRTUAL El término memoria virtual se usa para designar aquella memoria que no existe realmente pero que puede simularse usando algún proceso de gestión de la memoria existente. En nuestro caso, el término 'memoria virtual' hace referencia a la utilización de un área de disco como si se tratase de memoria. Con ello se puede superar la carencia de memoria extendida o expandida, si bien este sistema es más lento y requiere de espacio disponible en el disco. La aplicación se ha desarrollado intentando aprovechar todos los tipos de memoria que el equipo pueda tener instalados. El programa funciona sobre memoria convencional, mientras que las imágenes usan memoria extendida, expandida o 'virtual'. Para permitir el uso de memoria XMS y EMS se requiere de un driver o controlador de memoria residente que se especifica en el fichero de configuración CONFIG.SYS[14]. En este caso se han usado los controladores HIMEM.SYS y EMM386.EXE respectivamente. Además el programa requiere de unas rutinas para la detección y uso de la memoria a través de llamadas al controlador de memoria. Para el uso de la 'memoria virtual', basta con que exista espacio libre suficiente en el disco. Las funciones usadas por el programa para el manejo de la memoria se encuentran en los módulos MEMORIA, XMS, EMS y VMS. El uso de memoria XMS, EMS y 'virtual' para el almacenamiento temporal de las imágenes se explica más adelante en el apartado 4. 3.1.3 EL INTERFACE CON EL USUARIO. El auge experimentado por la informática ha traído consigo la preocupación cada vez más generalizada de proporcionar al usuario un entorno de trabajo cada vez más intuitivo y fácil de manejar. Esto se ha conseguido presentando programas que aprovechen las capacidades gráficas de las máquinas, ya que, resulta mucho más agradable trabajar con un interface gráfico que tener que aprender comandos y combinaciones de teclas para que la máquina realice una operación determinada. Un ejemplo claro de esto es el éxito de entornos y sistemas operativos como Windows u OS/2. Este proyecto trabaja bajo el sistema operativo DOS, pero presenta un interface gráfico basado en el ratón para facilitar al usuario el manejo del programa. El interface gráfico usado se basa en la pulsación con el ratón sobre unas 'teclas' o áreas dibujadas en la pantalla. Esta pulsación dará lugar a la ejecución de una acción (Por ejemplo, ver una imagen) o a la aparición de un nuevo menú en el que existen más teclas o áreas para seleccionar. El ratón (mouse) se ha convertido en un elemento imprescindible. El uso del ratón requiere la instalación del dispositivo físico (el ratón en sí y a veces una tarjeta controladora) y de un software controlador del ratón. El uso del ratón en un programa requiere tener instalado un manejador o driver de ratón, como MOUSE.COM suministrado con el DOS para ratones compatibles con Microsoft. El acceso al driver del ratón desde un programa se consigue usando la interrupción 33H de los procesadores de la familia ix86. Los distintos servicios de esta interrupción permiten inicializar el driver del ratón, indicar si hay un ratón instalado y su tipo (número de botones) en caso afirmativo. Otras funciones permiten conocer la posición actual del ratón, el estado de los botones (presionado o no), hacer visible o no el cursor del ratón en la pantalla, etc. Las funciones de manejo del ratón usadas por el programa se encuentran en el módulo RATON. El uso del ratón es necesario pero no suficiente. En ocasiones se hace necesaria la introducción de cadenas de caracteres o valores numéricos, para lo que se ha de recurrir al tradicional teclado. Las funciones para la gestión de las teclas y los menús se encuentran en los módulos TECLAS y MENU. Para más detalles sobre el interface gráfico, consultar el manual de uso de la aplicación. 3.1.4 IMPRESION. Toda aplicación debe ofrecer al usuario la posibilidad de obtener la información tratada por el programa en un soporte físico tangible, como es el papel. Para ello se usan las impresoras. Existen tres tipos de impresoras atendiendo a la tecnología usada para la impresión: Las impresoras matriciales se basan en la misma tecnología de las tradicionales máquinas de escribir: Un cabezal impacta sobre una cinta impregnada de tinta y estampa sobre el papel el símbolo deseado. El cabezal de una impresora matricial está compuesto por una columna de agujas (en número variable de 8 a 24) que serán las que impacten en la cinta, dando forma así al carácter impreso. Una impresora que se ha constituido como un estándar en las impresoras matriciales es la EPSON FX-80 de 9 agujas. Las impresoras de inyección de tinta sustituyen la cinta y las agujas de las matriciales, por unos inyectores de tinta que salpican el papel. Las impresoras láser producen la impresión usando un sistema similar al de las copiadoras, calentando un fino polvo de tinta llamado 'toner' que se adhiere al papel. Las impresoras usadas más comúnmente son en blanco y negro. Las impresoras de color son, por el momento, más caras y, por tanto, menos accesibles para el usuario. Uno de los principales problemas que surgen a la hora de imprimir una imagen de color es la de representar los colores de ésta en un dispositivo en blanco y negro como es la impresora. La mayoría de las modernas impresoras proporcionan códigos de control para hacer esta operación, encargándose ellas del proceso. Así, existen lenguajes de descripción de páginas como el PostScript. El PostScript fue desarrollado por Adobe y es reconocido por determinadas impresoras (usualmente con tecnología láser) que incluyen un intérprete de dicho lenguaje. Este trabajo se encarga de estudiar la problemática citada anteriormente sobre el color y propone soluciones para la impresión de las imágenes en impresoras EPSON FX80 (o compatibles) y PostScript. Los módulos encargados de la impresión de las imágenes son PSCRIPT y EPSON.3.2 SOFTWARE. Toda realización de un proyecto informático requiere la utilización de otro software que permita el desarrollo, implantación y prueba del sistema creado. Los programas usados en la elaboración del proyecto pueden dividirse en dos grupos principales: las herramientas constituyentes del sistema de desarrollo (editores, compiladores, etc.) y los programas de utilidad para verificar el funcionamiento del programa a desarrollar. 3.2.1 HERRAMIENTAS DE DESARROLLO. La aplicación ha sido desarrollada en casi su totalidad en lenguaje C, exceptuando un par de módulos que se han codificado en lenguaje ensamblador. El compilador de C usado ha sido el Turbo C++ 2.0 de Borland. El ensamblador ha sido el Turbo Assembler 1.0 de Borland. También se ha usado como guía de programación para ciertas rutinas el programa HelpPC 2.10 que ofrece información de utilidad sobre aspectos muy relacionados con la máquina. 3.2.2 PROGRAMAS DE UTILIDAD. Para realizar un control de fiabilidad de los ficheros de formatos gráficos generados por el programa, se hace necesaria la utilización de otros programas de conversión existentes en el mercado. Estos han sido: GWS 6.1 para DOS CSHOW 8.50a 3.3 LIMITACIONES Y POSIBLES AMPLIACIONES. 3.3.1 LIMITACIONES. Intentar abarcar en un solo proyecto todos los formatos gráficos sobre imágenes de mapas de bits existentes y todas las posibilidades ofrecidas por cada uno de ellos no es una tarea fácil de realizar. Por citar un ejemplo, las especificaciones completas de la versión 5.0 del formato TIFF constituyen un documento de alrededor de 40 páginas. Teniendo en cuenta la cantidad de posibilidades de codificación de las imágenes en este formato y los distintos métodos de compresión que usa, un programa codificador y decodificador de imágenes en formato TIFF podría constituirse por si solo en un proyecto de similar o mayor magnitud a éste. Así pues y como ya se esbozó en los objetivos, la aplicación contempla la lectura y escritura de imágenes de mapas de bits en los formatos más representativos del género y, dentro de cada uno de ellos, de los más usados en la actualidad. También se han de tener en cuenta las limitaciones del sistema informático usado. 3.3.2 POSIBLES AMPLIACIONES. Toda vez que se sientan las bases para la implantación de una aplicación, ésta es susceptible de ser modificada y mejorada hasta límites únicamente determinados por el propio autor de las modificaciones. Aspectos a mejorar y que podrían constituirse como objetivos para otro proyecto de mayor envergadura podrían ser: * Soporte para otros entornos operativos (Windows,UNIX). * Codificación de las rutinas en otros lenguajes. * Adición de nuevos formatos gráficos y ampliación de los ya tratados. Y en general todas las sugerencias que se puedan hacer para mejorar el programa y permitir el acceso al usuario al mundo de los gráficos por ordenador.4 ESTRUCTURA GENERAL DE LA APLICACION. FLUJO DE DATOS. Para que las aplicaciones gráficas puedan almacenar imágenes para su uso posterior, éstas deben guardarse en un fichero. Si cada aplicación utiliza su propio formato, el intercambio de imágenes entre aplicaciones implica la utilización de traductores de formatos. En un grupo de N aplicaciones con formatos diferentes, serán necesarios N*(N-1) traductores diferentes si se quieren compartir los datos entre todas las aplicaciones. El costo para desarrollar y mantener todos estos programas resulta prohibitivo. También resulta imposible pretender usar un sólo formato para todas las aplicaciones. En cambio si se puede usar un formato gráfico común o estándar gráfico de almacenamiento que sirva de paso intermedio para la traducción. Este mismo enfoque se traslada para la implementación del conversor entre formatos gráficos estándares. La transición entre los formatos se hace mucho más fácil si se adopta una estructura de datos en memoria común a todos ellos. Esta estructura de datos servirá como destino para cada uno de los módulos lectores o decodificadores de cada formato y, se constituirá a la vez como origen para los algoritmos de escritura o codificadores de cada formato. Esta estructura para el almacenamiento temporal de la imagen en memoria también será usada para la visualización, manipulación e impresión de las imágenes. 5 ESTRUCTURA DE LOS FICHEROS. FORMATOS GRAFICOS. Este capítulo se propone explicar la estructura de los distintos formatos gráficos tratados por la aplicación. Estos son: - TIFF (Tagged Image File Format). [1], [3], [7] y [11]. - PCX (PC Paintbrush). [1] y [6]. - MAC (MacPaint Files). [1]. - IMG/GEM (Ventura Publisher). [1] y [8]. - BMP (Windows 3.X). [2]. - TGA (Targa TrueVision). [11]. - GIF (Graphics Interchange Format). [1],[6],[9] y[10]. En el capítulo 3, se habla de la limitación de no poder tratar todos los formatos gráficos y todas las variantes que cada uno posee. En la siguiente tabla se muestran, para cada uno de los formatos usados, los tipos de imágenes susceptibles de ser leídas y escritas por la aplicación. FORMATO TIPO COMPRESION LECTURA ESCRITURA TIFF Hasta 256 colores CLASE B 32773 SI NO SIN COMPRIMIR SI SI CLASE G SIN COMPRIMIR SI SI CLASE P SIN COMPRIMIR SI SI CLASE R NO NO PCX MONOCROMO RUN-LENGTH SI SI 16 COLORES RUN-LENGTH SI SI 256 COLORES RUN-LENGTH SI SI MAC MPNT 32773 SI SI IMG/GEM MONOCROMO PROPIA SI SI 16 GRISES PROPIA SI SI 256 GRISES PROPIA SI SI BMP 2 A 256 COLORES SIN COMPRIMIR SI SI TGA (HASTA 256 COLORES) SIN COMPRIMIR SI SI GIF 87a LZW SI SI (256 COLORES) 89a LZW SI SI (256 COLORES) 5.1 EL FORMATO TIFF (Tagged Image File Format) GENERALIDADES SOBRE LOS FICHEROS TIFF Ha sido desarrollado conjuntamente por Microsoft Corp. y Aldus Corp. (el creador de PageMaker) para estandarizar los formatos gráficos usados en autoedición. Su potencia lo ha consolidado como uno de los estándares en el intercambio de imágenes digitales. Es independiente del microprocesador, la tarjeta de vídeo, el sistema operativo y la organización de los discos. Un fichero TIFF puede alcanzar hasta 232 bytes ya que usa punteros de 4 bytes para referenciar desplazamientos. CARACTERISTICAS DE LOS FICHEROS TIFF A diferencia de la mayoría de los formatos existentes, TIFF es un formato dinámico, esto es, los datos no se guardan en una posición determinada del fichero, sino que pueden variar su posición de un fichero a otro y lo que es más importante es que es fácilmente modificable a la hora de añadir nuevas características que definan la imagen. Los ficheros TIFF pueden contener imágenes de cualquier tipo, desde monocromáticas hasta color real, aceptan distintos tipos de compresión y codificación, imágenes almacenadas por pixel o por planos. Todo ello se debe a la particular y eficaz estructura que el formato posee. La base de esta estructura son los Tags o etiquetas, a las que debe su nombre y que se estudian más adelante. AMBITO DEL ESTUDIO Intentar abarcar todas las posibilidades que los ficheros TIFF ofrecen sería una tarea que daría material para constituirse en una obra por sí misma. No obstante, los creadores del formato han definido cuatro tipos de ficheros TIFF que atienden a unos requisitos mínimos con objeto de poder encasillar los ficheros y hacer más fácil su estudio. En esta obra se estudian estos tipos de ficheros TIFF y la forma de reconocerlos, así como la implementación de los más característicos: Monocromos, Grises y de Color, estos últimos hasta 256 colores. El método de compresión estudiado será el PackBits usado también en los fichero MacPaint. ESTRUCTURA DE UN FICHERO TIFF Como se señaló antes, el formato TIFF es dinámico y la información en él contenida puede no estar siempre codificada de la misma forma. Lo que si son invariables son sus tres elementos principales: - Cabecera. - Directorio de Tags o IFDs ( Image File Directory) - Datos. Pasemos a estudiarlos detenidamente. CABECERA Es el único elemento con posición fija. Ocupa siempre los 8 primeros bytes del fichero y su estructura es la siguiente: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 2 formato Formato de almacenamiento 'II' : Intel 'MM' : Motorola 2 2 identificador Número de la versión = 42 4 4 pixels_por_linea Puntero al primer IFD o directorio de Tags El primero de los campos (formato) sirve para determinar si los bytes se almacenan con formato Intel (De menos a más significativo) o Motorola (De más a menos significativo). El segundo (identificador) es la versión. Realmente es una constante que vale siempre 42, aunque el fichero pertenezca a una versión u otra. El tercer y último campo es un puntero de 32 bits que indica el lugar dentro del fichero donde se encuentra el primer IFD o directorio de Tags, cuya estructura se explica a continuación.DIRECTORIO DE TAGS o IFD Un IFD se compone de: - Un número de 2 bytes que indica el número de tags que contiene el directorio. - Uno o más tags, hasta completar el número de tags. - Un puntero al siguiente IFD. En caso de no existir más IFDs, este campo valdrá 0000. A continuación se estudian los tags.TAG. La estructura de los datos. El término tag puede traducirse como etiqueta o campo. Es un elemento de 12 bytes asociado a algún parámetro de la imagen almacenada en el fichero TIFF. Así un tag puede indicar el ancho del fichero, el número de colores, la posición de inicio de la imagen, etc. La estructura de un tag es la siguiente: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 2 numero Número o identificador del tag 2 2 tipo Tipo del dato asociado al tag 1: BYTE 2: ASCII 3: SHORT 4: LONG 5: RATIONAL 4 4 longitud Longitud del dato asociado al tag 8 4 desplazamiento Puntero al dato o valor del dato El primer campo del tag (numero) es un entero de dos bytes que identifica al tag en cuestión. Dentro de un IFD, los tags deben estar ordenados en orden ascendente al número de tag. Más adelante se explican los tags usados en esta obra y el apéndice A muestra una lista de todos los tags de la versión 5. El segundo campo (tipo) es otro entero de dos bytes que indica el tipo de dato asociado al tag. Puede tener cinco valores posibles: 1 BYTE: Un número de 8 bits sin signo. 2 ASCII: Una Cadena de caracteres ascii, terminada en 0. 3 SHORT: Un número de 16 bits sin signo. 4 LONG: Un número de 32 bits sin signo. 5 RATIONAL: Dos números de 32 bits sin signo. El primero es el numerador y el segundo el denominador. El tercer campo (longitud) es la longitud de los datos asociados al tag. Este valor no se da en bytes, sino en número de elementos del tipo de tag. Por ejemplo, una longitud 2 para un tag de tipo SHORT (entero de dos bytes) supone un total de 4 bytes (dos elementos SHORT de dos bytes cada uno). En el caso del tipo ASCII, también se contabiliza el carácter nulo de terminación de la cadena de caracteres. El cuarto y último campo (desplazamiento) puede tener dos funciones: 1. Por definición es un puntero de 4 bytes que indica el desplazamiento dentro del fichero donde se encuentran los datos asociados con el tag. Esto ocurre normalmente cuando se trata de una cadena de caracteres (el nombre del autor de la imagen) o una sucesión de números (la paleta de colores). 2. Cuando se trata de un valor de tipo BYTE, SHORT o LONG, los cuatro últimos bytes del tag no almacenan el puntero al valor, sino el propio valor, ahorrando con ello espacio en el fichero. TAGS USADOS POR LA APLICACION La estructuración en tags permite al formato una gran flexibilidad y dinamismo, así como la posibilidad de añadir nuevas definiciones de tags a medida que se vayan necesitando. Por otra parte el programa decodificador del fichero TIFF puede ignorar los tags que no necesite. En algunos casos, cuando un tag no aparece, toma un valor por defecto. Este apartado explica los tags usados en la aplicación. Para cada uno se enumeran su nombre (Se ha respetado el idioma inglés), su número (en decimal y hexadecimal), su tipo y longitud. BitsPerSample Tag : 258 (102) Tipo : SHORT Longitud: SamplesPerPixel Es el número de bits por muestra. Permite, junto con SamplesPerPixel determinar el espacio que ocupa un pixel. Notar que este tag permite un número diferente de bits por muestra para cada muestra correspondiente a un pixel. Por ejemplo, los datos de color RGB podrían usar un número diferente de bits por muestra para cada uno de los tres planos de color. La mayoría de los ficheros RGB tienen el mismo número de BitsPerSample para cada muestra. Por defecto es 1. Ver también SamplesPerPixel. ColorMap Tag : 320 (140) Tipo : SHORT Longitud: 3 * (2**BitsPerSample) Tabla de colores. Este tag define una tabla o paleta de colores RGB formada por tres subcurvas (Rojo, Verde y Azul). El valor de color del pixel es usado como índice a las 3 subcurvas. Por ejemplo, un pixel con el valor 0 será visualizado de acuerdo con la entrada 0 de cada una de las subcurvas. Las subcurvas son almacenadas secuencialmente. Primero las entradas de rojo, seguidas por las entradas de verde y las de azul. La longitud de cada subcurva es 2**BitsPerSample. Una paleta para una imagen de 8 bits de color (256 colores) tendrá 3 * 256 entradas. El ancho de cada entrada es de 16 bits (tipo SHORT). El 0 representa la mínima intensidad y 65535 representa la máxima intensidad. El negro se representa por 0,0,0, y el blanco por 65535, 65535, 65535. El propósito de la tabla de colores (lookup table) es mapear los valores de los pixels desde 0 hasta 2**BitsPerSample-1 en triples RGB. El campo ColorResponseCurves puede ser usado conjuntamente con ColorMap para refinar los colores RGB del campo ColorMap. No hay paleta de color por defecto. ColorMap debe ser incluido en todas las imágenes de paleta de color. Compression Tag : 259 (103) Tipo : SHORT Longitud: 1 Tipo de compresión usado: 1 = No comprimido. Los bytes son almacenados en un array de tipo BYTE si BitsPerSample <=8, en uno de tipo SHORT si BitsPerSample >8 y <=16, y en uno de tipo LONG si BitsPerSample >16 y <=32. El orden de los bytes de datos >8 bits debe estar en consonancia con lo especificado en los bytes 0 y 1 de la cabecera del fichero en lo referente a los formatos Intel ('II') y Motorola ('MM'). Si el número de bits por muestra no es potencia de 2, es recomendable usar la siguiente potencia de 2 perdiendo así en espacio pero ganando en rendimiento a la hora del tratamiento de las imágenes. 2 = CCITT Group 3 1-Dimensional Modified Huffman run length encoding. 3 = Facsimile-compatible CCITT Group 3. 4 = Facsimile-compatible CCITT Group 4. 5 = LZW. Usado para escala de gris, mapa de color e imágenes RGB de color real. 32773 = PackBits. Es un simple esquema run-length para imágenes de 1 bit. El algoritmo es el mismo usado para la descompresión de ficheros MacPaint. El método es el siguiente: Se lee un byte del fichero. Si el bit más significativo de este byte vale 0, se usa como contador para indicar cuántos bytes han de leerse del fichero como bytes de datos. Si el bit menos significativo vale 1, se le hace el complemento a dos y se usa como contador para indicar cuántas veces se usará el siguiente byte del fichero como byte de dato. El algoritmo de lectura: PARA cada byte "c" leído del fichero SI el bit más significativo de "c" vale 0 contador = siguiente byte del fichero MIENTRAS contador > 0 dato = siguiente byte del fichero contador = contador - 1 FIN MIENTRAS SINO ( el bit más significativo de "c" vale 1) contador = complemento a dos de "c" dato = siguiente byte del fichero FINSI En esta aplicación se leen ficheros TIFF sin comprimir y comprimidos usando este último método. Los ficheros TIFF generados por la aplicación no usan método de compresión. Para terminar con el tema de la compresión, conviene decir que ésta sólo afecta a los datos de la imagen apuntados por el campo StripOffsets. Toda la información restante no es comprimida. Por defecto es 1. ImageLength Tag : 257 (101) Tipo : SHORT o LONG Longitud: 1 Es el alto de la imagen en pixels (Y: vertical). El número de líneas de la imagen, llamado a veces 'scan lines'. Ver también ImageWidth. No hay valor por defecto. ImageWidth Tag : 256 (100) Tipo : SHORT o LONG Longitud: 1 El ancho de la imagen en pixels (X: horizontal). Es el número de columnas de la imagen. Ver también ImageLength. No hay valor por defecto. NewSubfileType Tag = 254 (FE) Tipo = LONG N = 1 Reemplaza al antiguo SubfileType debido a las limitaciones de éste. Da una indicación general del tipo de los datos contenido en el fichero. Es un registro de 32 bits, usados como banderas. Los bits que no se usan deben ser 0. El bit 0 es el menos significativo. Los valores definidos actualmente son: Bit 0: 1 si la imagen es una versión reducida; si no el bit es 0. Bit 1: 1 si la imagen es una página de una imagen con múltiples páginas; si no el bit es 0. Bit 2: 1 si la imagen define una máscara de transparencia. En este caso PhotometricInterpretation bebe ser 4. Por defecto vale 0. PhotometricInterpretation Tag : 262 (106) Tipo : SHORT Longitud: 1 Interpretación fotométrica. 0 = Para imágenes monocromas y de tonos de gris. El 0 es el blanco y 2**BitsPerSample-1 es el negro. 1 = Para imágenes monocromas y de tonos de gris. El 0 es el negro y 2**BitsPerSample-1 es el blanco. 2 = RGB. En el modelo RGB, un color es descrito como una combinación de los tres colores primarios de la luz (rojo, verde y azul) en concentraciones particulares. Para cada una de las tres muestras, el 0 representa la mínima intensidad y 2**BitsPerSample - 1 representa la máxima intensidad. Así un valor RGB de (0,0,0) representa el negro y (255,255,255) representa el blanco, asumiendo muestras de 8-bit. Para PlanarConfiguration = 1, las muestras son almacenadas una a una en el orden indicado: primero rojo, después verde y después azul. Para PlanarConfiguration = 2, las muestras son almacenadas por planos en el orden indicado: primero rojo, después verde y después azul. El campo ColorResponseCurves puede ser usado para refinar los colores. 3 = Paleta de color. En este modo, un color es descrito con una simple muestra. La muestra es usada como un índice al mapa de color definido por ColorMap y obtener así el triple RGB definido para ese pixel. Cuando se usa este valor para PhotometricInterpretation, la paleta de color debe de ser suministrada. SamplesPerPixel debe valer 1. 4 = Máscara de transparencia. Esto significa que la imagen es usada para definir una región irregularmente formada de otra imagen en el mismo fichero. SamplesPerPixel y BitsPerSample deben ser 1. Se recomienda usar la compresión PackBits. Los bits a 1 definen el interior de la región, los bits 0 el exterior de la región. La máscara de transparencia debe tener los mismos ImageLength e ImageWidth que la imagen principal. Una aplicación que lea la imagen puede usar la máscara para determinar que partes de la imagen visualizará. Los pixels de la imagen principal a los que correspondan bits a 1 en la máscara de transparencia serán visualizados, pero los pixels de la imagen a los que correspondan bits a 0 en la máscara, no serán visualizados. No hay valor por defecto. PlanarConfiguration Tag : 284 (11C) Tipo : SHORT Longitud: 1 Expresa el modo en el que los datos de la imagen son guardados. 1: Los valores de la muestra para cada pixel son guardados contiguamente, es decir en un único plano. Así, para datos RGB, éstos son guardados RGBRGBRGB... uno tras otro. 2: Las muestras son guardadas en planos separados. Para datos RGB, estos son guardados con las muestras de rojo en un plano, las de verde en otro y las de azul en otro. Si SamplesPerPixel es 1, PlanarConfiguration es irrelevante, y no debe incluirse. Por defecto vale 1. Ver también BitsPerSample, SamplesPerPixel. ResolutionUnit Tag : 296 (128) Tipo : SHORT Longitud: 1 Indica la unidad usada para medir la resolución. Es usada con XResolution e YResolution. 1 = No hay unidad de medida. 2 = Pulgadas. 3 = Centímetros. Por defecto vale 2. Ver también XResolution, YResolution. RowsPerStrip Tag : 278 (116) Tipo : SHORT o LONG Longitud: 1 El número de filas por bloque. Los datos de la imagen se organizan en bloques para un acceso más rápido a filas individuales cuando los datos están comprimidos. Este campo es válido incluso si los datos no están comprimidos. RowsPerStrip e ImageLength juntos indican el número de bloques de la imagen. La ecuación es: StripsPerImage=(ImageLength+RowsPerStrip-1)/RowsPerStrip asumiendo aritmética de enteros. Por defecto vale 2**32 - 1, que es infinito. Esto es, la imagen entera es un bloque. No se recomienda. Debe escogerse un RowsPerStrip tal que cada bloque sea de unos 8K bytes. Es un tamaño arbitrario pero la práctica demuestra su eficiencia. Ver también ImageLength, StripOffsets, StripByteCounts. SamplesPerPixel Tag : 277 (115) Tipo : SHORT Longitud: 1 El número de muestras por pixel. Permite, junto con BitsPerSample determinar el espacio que ocupa un pixel. SamplesPerPixel es 1 para imágenes monocromas, escala de gris y paleta de color. SamplesPerPixel es 3 para imágenes RGB. Por defecto es 1. Ver también BitsPerSample, PhotometricInterpretation. StripByteCounts Tag : 279 (117) Tipo : SHORT o LONG Longitud:StripsPerImage si PlanarConfiguration vale 1. SamplesPerPixel * StripsPerImage si PlanarConfiguration es 2. Indica, para cada bloque, el número de bytes en cada bloque. La existencia de este campo simplifica el tratamiento de buffers cuando los datos están comprimidos si el tamaño del bloque es razonable. No hay valor por defecto. Ver también StripOffsets, RowsPerStrip. StripOffsets Tag : 273 (111) Tipo : SHORT o LONG Longitud:StripsPerImage si PlanarConfiguration vale 1. SamplesPerPixel * StripsPerImage si PlanarConfiguration es 2. Indica para cada bloque el desplazamiento de ese bloque. El desplazamiento es especificado con respecto al inicio del fichero TIFF. Nótese que esto implica que cada bloque tiene una localización independiente de las localizaciones de otros bloques. Este campo es la única forma que tienen los programas lectores de ficheros TIFF para encontrar los datos de la imagen y por tanto debe existir. No hay valor por defecto. Ver también StripByteCounts, RowsPerStrip. XResolution Tag : 282 (11A) Tipo : RATIONAL Longitud: 1 El número de pixels por ResolutionUnit en la dirección X. No hay valor por defecto. Ver también YResolution, ResolutionUnit. YResolution Tag : 283 (11B) Tipo : RATIONAL Longitud: 1 El número de pixels por ResolutionUnit en la dirección Y. No hay valor por defecto. Ver también XResolution, ResolutionUnit. CODIFICACION Una vez vista la estructura de los ficheros TIFF y los tags más usados sólo resta saber cuales son los tipos de ficheros TIFF más comunes y cómo identificarlos. Como se ha apuntado anteriormente, se han definido 4 clases de ficheros TIFF: Clase B para imágenes monocromas. Clase G para imágenes de tonos de gris. Clase P para imágenes con paleta de color. Clase R para imágenes RGB de color real. También se define la Clase X para llamarlas a todas de forma genérica. Todas las clases poseen unos requerimientos generales y otros específicos. REQUERIMIENTOS GENERALES Los programas que generan ficheros TIFF pueden estipular algunos valores por defecto, pero no es imprescindible. Por otra parte, los programas decodificadores deben estar preparados para leer campos (tags) no requeridos. Deben ser capaces de leer en los formatos 'II' y 'MM'. Deben estar preparados para leer ficheros que contienen múltiples imágenes. Esto es recomendable pero no obligatorio. En estos casos, la primera imagen debe tener la resolución máxima. Las siguientes, tales como reducciones y máscaras de transparencia pueden estar en cualquier orden. En este estudio no se tratan estas subimágenes. Los campos o tags requeridos por los cuatro tipos de imágenes son los siguientes: NewSubfileType. LONG. Para permitir múltiples imágenes. Se recomienda pero no es imprescindible, puede ignorarse. ImageWidth. SHORT o LONG. Indica el ancho de la imagen. ImageLength. SHORT o LONG. Indica el alto de la imagen. RowsPerStrip. SHORT o LONG. Permite la carga de la imagen por bloques. StripOffsets. SHORT o LONG. Relacionado también con la lectura de la imagen, ya que indica donde comienzan los bloques de imagen, depende de los campos RowsPerStrip e ImageLength. StripByteCounts. SHORT o LONG. Relacionado con la codificación del fichero, no es estrictamente necesario. XResolution, YResolution. RATIONAL. Su tratamiento depende del tipo de aplicación que trate las imágenes. En nuestro caso no se necesitan tener en cuenta. ResolutionUnit. SHORT. Es recomendable que los lectores puedan ser capaces de manejar las tres posibles unidades de resolución. A continuación se estudian las cuatro clases de TIFF y los campos que definen a cada una de ellas, así como los valores que los campos deben tener. CLASE B. MONOCROMOS. TAG TIPO VALOR COMENTARIO SamplesPerPixel SHORT 1 Por defecto BitsPerSample SHORT 1 1 bit por pixel Compression SHORT 1 Sin comprimir 2 CCITT 32773 PackBits PhotometricInterpretation SHORT 0 1 Como era de esperar los ficheros B utilizan un bit por pixel para representar las imágenes. El color representado por cada bit depende de la interpretación fotométrica. CLASE G. ESCALA DE GRISES. TAG TIPO VALOR COMENTARIO SamplesPerPixel SHORT 1 BitsPerSample SHORT 4 8 Compression SHORT 1 Sin comprimir 5 LZW PhotometricInterpretation SHORT 0 1 Los ficheros de escala de grises, usan un número que representa el tono de gris del pixel en una paleta de grises. La paleta puede aparecer o no. Los ficheros de este tipo son una variación de los de paleta de color.CLASE P. PALETA DE COLORES. TAG TIPO VALOR COMENTARIO SamplesPerPixel SHORT 3 Rojo, Verde y Azul BitsPerSample SHORT 1..8 Compression SHORT 1 Sin comprimir 5 LZW PhotometricInterpretation SHORT 3 Paleta de color ColorMap SHORT Indice Indice a la paleta Los ficheros de paleta de color, usan un número que representa el color del pixel en una paleta de colores RGB. CLASE R. COLOR REAL RGB. TAG TIPO VALOR COMENTARIO SamplesPerPixel SHORT 3 BitsPerSample SHORT 8 Compression SHORT 1 Sin comprimir 5 LZW PhotometricInterpretation SHORT 2 RGB PlanarConfiguration SHORT 1 Contiguo 2 Por planos Los ficheros de color real RGB, usan un trío RGB para representar cada pixel. No requieren paleta de colores y la información puede venir contiguamente o por planos.5.2 EL FORMATO PCX (PC PAINTBRUSH) GENERALIDADES SOBRE LOS FICHEROS PCX El formato PCX fue desarrollado para uso del programa PC Paintbrush, una aplicación de dibujo de la compañía ZSoft. La evolución experimentada por el programa (Existe una potente versión para el entorno Windows), lo ha convertido en uno de los programas de mayor éxito dentro de su ámbito, lo cual ha dado lugar a que el formato PCX se haya consolidado como uno de los estándares gráficos más usados para el intercambio de imágenes entre aplicaciones de este tipo. CARACTERISTICAS DE LOS FICHEROS PCX Los ficheros PCX pueden contener una imagen monocromática o de color, variando el número de colores desde los 4 de las primeras versiones de Paintbrush para CGA hasta los actuales ficheros de imágenes de color real (True Color). AMBITO DEL ESTUDIO Dado que los sistemas CGA están prácticamente obsoletos y el color real requiere de potentes tarjetas de video para su visualización, el presente estudio abarcará los ficheros monocromos y los de 16 y 256 colores. ESTRUCTURA DE UN FICHERO PCX El formato PCX es un formato fijo: la información sobre la estructura del gráfico y los datos propios de la imagen se almacenan en campos definidos siempre en la misma posición del fichero. Los ficheros PCX tienen una cabecera de 128 bytes en la que se encuentra la información del gráfico que incluye una paleta de 16 colores. Tras ésta, se encuentran los datos, comprimidos según la técnica run-length, que se explicará más adelante. Opcionalmente, si el gráfico soporta 256 colores, tras los datos aparece una paleta de 256 colores. CABECERA La cabecera presenta la siguiente estructura: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 1 fabricante Cte = 10 (0xA) 1 1 versión Versión de la imagen: 0: 2.5 2: 2.8 con paleta de color 3: 2.8 sin paleta de color 4: Paintbrush para Windows 5: Versiones 3.0 o posteriores 2 1 codificacion Cte = 1, compresión run-length 3 1 bits_por_pixel Nº de bits por pixel por plano 4 2 xmin Coordenada x superior izquierda 6 2 ymin Coordenada y superior izquierda 8 2 xmax Coordenada x inferior derecha 10 2 ymax Coordenada y inferior derecha 12 2 ppp_hor Resolución horizontal en ppp 14 2 ppp_ver Resolución vertical en ppp 16 48 paleta Paleta de colores (hasta 16) 64 1 reservado No usado 65 1 planos_color Nº planos de color 66 2 bytes_por_línea Nº de bytes por línea 68 2 tipo_paleta Interpretación de la paleta: 1: B/N 2: Escala de grises 70 58 relleno Relleno hasta completar 128 bytes El primer byte (fabricante) es una constante que vale siempre 10 (0xA en hexadecimal y sirve para identificar los ficheros PCX. El segundo (versión) indica la versión de Paintbrush con la que se creó la imagen. Además indica también si se debe o no usar la paleta que trae el dibujo. Cuando este byte vale 5, Paintbrush entiende que la paleta está activada y respeta el color del gráfico. Si vale 3, se usa la paleta en uso del sistema. El tercero (codificación) es una constante de valor uno que indica que el gráfico está codificado según una técnica run_length orientada a byte que se explicará más adelante. El cuarto byte (bits_por_pixel) indica el numero de bits requeridos para representar un pixel. A continuación aparecen cuatro enteros de dos bytes (xmin,ymin,xmax,ymax) que representan las esquinas superior izquierda e inferior derecha de la imagen en pantalla. Por lo general la esquina superior suele ser la (0,0), por lo que la esquina inferior indica frecuentemente la altura y ancho de la imagen. Los dos enteros siguientes (ppp_hor,ppp_ver) indican la resolución de la imagen, en puntos por pulgada, horizontal y verticalmente. Los 48 bytes siguientes (paleta) contienen la información relativa a la paleta de colores. Esta información se interpreta de forma distinta según la tarjeta de vídeo usada. En una tarjeta EGA (16 colores), los datos se almacenan como 16 triples de 3 bytes cada uno, cada triple es un valor RGB, indicando cada byte del triple la cantidad de rojo, verde y azul. En una tarjeta CGA (2 colores), sólo se usa el primer byte de cada triple de la siguiente forma: el primer byte del primer triple, representa el color de fondo, el cual se halla dividiendo el byte sin signo entre 16 para obtener un valor entre 0 y 15. El primer byte del segundo triple representa el color de la figura. Como Paintbrush soporta 8 paletas CGA, el color de la figura se codifica como un número de 0 a 255 con 8 rangos de números cada 32 (0..31, 32..63,224..255). En una tarjeta VGA (256 colores), la información almacenada en esta paleta de 48 bytes no tiene sentido puesto que no sirve para guardar una paleta de 256 colores. En este caso, la paleta se encuentra situada al final del fichero, tras la imagen codificada. Tras la paleta, y continuando con la cabecera, aparece un byte que no tiene uso (reservado). El siguiente byte (planos_color) indica el número de planos de colores. Conociendo el nº de planos y el nº de bits por pixel, se obtiene el nº de colores. Tras el nº de planos aparecen los bytes por línea (bytes_por_línea), necesarios para la decodificación de la imagen. Para terminar el tipo de paleta (tipo_paleta) expresa si la imagen es monocroma o de escala de grises. El resto (relleno) es un relleno hasta completar los 128 bytes de la cabecera. CODIFICACION DE LA IMAGEN La imagen puede venir codificada por pixels o por planos. En el primer caso, los pixels vienen codificados uno tras otro hasta completar la línea, por lo que, bastará con leer la línea del fichero para obtener la línea de la imagen. Esto ocurrirá con las imágenes monocromáticas y de 256 colores. En el segundo, cada línea de la imagen viene codificada por planos en el orden RGBI (Rojo, verde, azul e intensidad) de la forma siguiente: Línea 0: RRR... GGG... BBB... III... Línea 1: RRR... GGG... BBB... III... ... Por lo que, cada línea leída del fichero, deberá ser escrita en su plano correspondiente, siendo necesario leer 4 líneas de fichero para obtener una línea de la imagen. Este es el caso de imágenes de 16 colores que suelen venir codificadas de esta forma para acomodarse mejor a la estructura de las tarjetas de video EGA y a las VGA en modo 16 colores. El método de compresión usado por los ficheros PCX se denomina run-length. Es un método orientado a la compresión a nivel de bytes, agrupando sucesiones de bytes iguales en un paquete que contiene un contador seguido del dato que se repite. El método es el siguiente: PARA cada byte "c" leído del fichero SI los 2 bits más significativos de "c" valen 1 contador = 6 bits menos significativos de "c" dato = siguiente byte a "c" SINO contador = 1 dato = "c" FINSI Según toda la documentación consultada, los paquetes deben ajustarse a la longitud de una línea. No debe aparecer un paquete con un contador que sumado al nº de bytes leídos, supere la longitud total de bytes de la línea. Sin embargo algunos programas de conversión usados durante el desarrollo de este estudio, con objeto de generar ficheros más compactos, agrupan en un solo paquete tantos bytes como el contador les permite (hasta 63) aunque parte de estos bytes pertenezcan a la siguiente línea. Este aspecto enrarece un poco el algoritmo de descompresión que, antes de tratar una nueva línea, debe comprobar si existen bytes pertenecientes a esta línea tratados en la anterior. Para resolver esto, se ha recurrido a la utilización de variables estáticas que "recuerdan" a la función descompresora de líneas los bytes sobrantes de la línea anterior. LA PALETA DE 256 COLORES Esta paleta está estructurada de la misma forma que la paleta EGA, pero en esta ocasión se trata de 256 triples RGB, por lo que se sitúa a partir de la posición -768 contando desde el final del fichero. El byte anterior (el -769) debe valer 12 y el campo versión de la cabecera debe contener el valor 5.5.3 EL FORMATO MAC (MACPAINT) GENERALIDADES SOBRE FICHEROS MAC Los ficheros MAC tiene su origen en los computadores Apple Macintosh. Este formato surgió ante la necesidad de establecer un puente de comunicación con otros entornos para el intercambio de las imágenes. CARACTERISTICAS DE LOS FICHEROS MAC Tienen un formato fijo. El tamaño del fichero varía por la compresión de los datos, pero todas las imágenes de este formato tienen tamaño fijo: 576x720. Son monocromos, lo que implica que cada byte contiene 8 pixels, por lo que para cada línea se requieren 576/8 = 72 bytes. ESTRUCTURA DE UN FICHERO MAC Los ficheros MAC poseen una cabecera que puede ser de 640 o 512 bytes seguidos de la imagen codificada según un método run-length que se explica más adelante. Al tener su origen en los ordenadores Apple Macintosh, estos ficheros contienen los números en formato Motorola, en el que los bytes menos significativos de una palabra se encuentran en último lugar, al contrario que en el formato Intel. CABECERA La cabecera estándar de un fichero MAC tiene una longitud de 640 bytes y su estructura es la siguiente: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 1 byte0 Cte = 0 1 1 longitud Longitud nombre del fichero (0-31) 2 63 nombre nombre del fichero 65 4 tipo Cadena constante = "PNTG" 69 4 creador Cadena constante = "MPNT" 73 10 relleno1 No usado 83 4 tam_datos Tamaño de los datos 87 4 tam_codigo Tamaño del código 91 4 fecha_creacion Fecha de creación 95 4 fecha_modifi Fecha de modificación 99 33 relleno2 No usado 132 304 patrones 38 patrones de 8 bytes 436 204 relleno3 No usado El primer elemento de la cabecera (byte0) es un byte de valor cero. El segundo (longitud) es otro byte que indica la longitud del nombre del fichero. Su valor oscila entre 0 y 31. El tercero (nombre) es el nombre del fichero, su longitud viene determinada por el contenido del campo anterior. Ocupa 63 bytes. El cuarto (tipo) es una constante que identifica el tipo de fichero. Su valor es "PNTG". El quinto (creador) indica el origen del fichero. También es una constante. Su valor es "MPNT" (MacPaiNT). A continuación aparece un campo reservado (relleno1). El siguiente campo (tam_datos) es un entero de 4 bytes que expresa el tamaño de los datos. El séptimo (tam_código) no se usa. debe valer cero. Los dos siguientes campos indican (fecha_creación y fecha_modificacion) indican las fechas de creación y última modificación del fichero. Los siguientes 33 bytes (relleno2) no se usan. El penúltimo campo de la cabecera (patrones) agrupa 38 patrones de 8 bytes cada uno. Al final de la cabecera aparecen 204 bytes para completar los 640 bytes (relleno3). Aunque ésta es la cabecera estándar de los ficheros MAC, algunos ficheros MAC creados por determinados programas, son generados con una cabecera de 512 bytes en blanco, es decir con todos sus bytes a cero. Ninguna de las dos cabeceras sirve de mucho a la hora de extraer el gráfico, ya que en estos ficheros se sabe de antemano toda la información necesaria para hacerlo. Así pues puede ignorarse la cabecera, aunque sí es necesario detectar de cual de las dos se trata para determinar el comienzo de los datos de la imagen. CODIFICACION Los fichero MAC usan un método de compresión de bytes iguales. El método es el siguiente: Se lee un byte del fichero. Si el bit más significativo de este byte vale 0, se usa como contador para indicar cuántos bytes han de leerse del fichero como bytes de datos. Si el bit menos significativo vale 1, se le hace el complemento a dos y se usa como contador para indicar cuántas veces se usará el siguiente byte del fichero como byte de dato. El algoritmo de lectura: PARA cada byte "c" leído del fichero SI el bit más significativo de "c" vale 0 contador = siguiente byte del fichero MIENTRAS contador > 0 dato = siguiente byte del fichero contador = contador - 1 FIN MIENTRAS SINO ( el bit más significativo de "c" vale 1) contador = complemento a dos de "c" dato = siguiente byte del fichero FINSI Cada línea del fichero debe tener siempre 72 bytes una vez descompactada. Esto permite detectar en caso de duda si se trata o no de un fichero MAC.5.4 EL FORMATO IMG/GEM A mediados de los 80 la compañía Digital Research lanzó al mercado el entorno gráfico GEM, bajo el cual se hizo popular el ya mítico programa de autoedición Ventura Publisher. Este programa utilizaba imágenes importadas en formato IMG, también diseñado por Digital Research para GEM. CARACTERISTICAS DE LOS FICHEROS IMG Originariamente, los ficheros IMG eran monocromáticos, aunque en la actualidad han evolucionado y existen versiones de 16 y 256 colores. A pesar de ello, la ausencia de una paleta de colores en estos últimos hace que los programas de tratamiento de ficheros gráficos le asignen una paleta de tonos de grises para su visualización. Existe una versión vectorial y otra bitmap de estos ficheros. Esta última es la tratada en este estudio. ESTRUCTURA DE UN FICHERO IMG Los ficheros IMG poseen una cabecera de 16 bytes formada por 8 enteros de 2 bytes, que se encuentran en formato MOTOROLA. Tras la cabecera se encuentra la imagen codificada según una técnica especial variante de una compresión RLE. CABECERA La estructura de una cabecera de un fichero IMG es la siguiente: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 2 id1 Cte = 1 2 2 id2 Cte = 8 4 2 planos Nº de planos: 1,4 o 8 6 2 longitud Longitud del patrón: 1 8 2 ancho_pixels Ancho del pixel en micras (85 micras = 1/300 pulgadas) 10 2 alto_pixels Alto del pixel en micras 12 2 ancho_linea Ancho de la imagen en pixels 14 2 alto_imagen Alto de la imagen en pixels Es importante recordar que los enteros se encuentran en formato MOTOROLA, con los bytes cambiados de orden con respecto al formato INTEL. Los dos primeros (id1 e id2) sirven para identificar los ficheros IMG. Deben valer 1 y 8 respectivamente. El segundo indica también el tamaño de la cabecera en bytes. El tercer entero (planos) indica el número de planos de color de la imagen. Si la imagen es monocromática vale 1. Si tiene 16 colores, su valor es 4. Por último si posee 256 colores el campo vale 8. El cuarto entero (longitud) es un número de bytes a repetir en el proceso de descompresión de la imagen. Se usa cuando se descomprime un 'pattern run'. Se verá más adelante. El quinto y sexto enteros (ancho_pixels y alto_pixels) indican el tamaño en micras del pixel en el dispositivo donde se creó la imagen. Ninguno de estos campos se usa para nada. El séptimo y octavo (ancho_linea y alto_imagen) indican las dimensiones de la imagen. CODIFICACION El formato IMG posee 4 variantes de compresión que pueden coexistir en un mismo fichero: Líneas repetidas (Replication packet). Consiste en la repetición de líneas completas dentro de la imagen. Si al leer los tres primeros bytes de la línea éstos poseen los valores hexadecimales 00 00 FF, la línea se repetirá tantas veces como indique el cuarto byte leído. La línea estará a partir del quinto byte. Paquete sólido (Solid Run). Cada byte leído tiene un color, blanco o negro que viene determinado por el bit de mayor peso de ese byte. Si el bit vale 0 el color es blanco y si vale 1 es negro. Los siete bits restantes indican el número de veces que hay que repetir el color. Patrón repetido (Pattern Run). El cuarto byte de la cabecera (longitud) indica la longitud que posee el pattern run. Si el byte leído del fichero vale 00, el siguiente byte leído indica el número de veces que hay que repetir el numero de bytes que indica la longitud del pattern run. Ej: Si la secuencia leída es 00 04 07 1A, indica lo siguiente: Es un pattern run ya que el primer byte vale 00. El segundo byte es el numero de veces a repetir el pattern, en este caso vale 4. Si suponemos que el campo longitud de la cabecera tiene el valor 2, entonces hay que repetir 4 veces los 2 siguientes bytes del fichero ( 07 1A) con lo que se obtendría la secuencia: 07 1A 07 1A 07 1A 07 1A. Cadena de bits (Bit String). Si el byte leído del fichero vale 80h, el siguiente byte indica el número de bytes que se deben leer para pintarlos en la pantalla. Estos bytes no se repiten. En realidad no comprime. A la hora de visualizar un fichero IMG hay que tener en cuenta dos aspectos: 1. Los bytes leídos del fichero no contienen la información por pixel, sino por planos. En las imágenes monocromáticas el número de planos es uno con lo que cada bit leído representa un pixel. En las imágenes de 16 colores, el número de planos es cuatro. Cada línea de la imagen viene codificada por planos en el orden RGBI (Rojo, verde, azul e intensidad) de la forma siguiente: Línea 0: RRR... 2────────────────────0 Plano Rojo GGG... 2────────────────────0 Plano Verde BBB... 2────────────────────0 Plano Azul III... 2────────────────────0 Plano Intensidad ││└───────────────0 3er pixel de la línea 0 │└────────────────0 2º pixel de la línea 0 └─────────────────0 1er pixel de la línea 0 Línea 1: RRR... 2────────────────────0 Plano Rojo GGG... 2────────────────────0 Plano Verde BBB... 2────────────────────0 Plano Azul III... 2────────────────────0 Plano Intensidad ││└───────────────0 3er pixel de la línea 1 │└────────────────0 2º pixel de la línea 1 └─────────────────0 1er pixel de la línea 1 Por lo que, cada línea leída del fichero, deberá ser escrita en su plano correspondiente, siendo necesario leer 4 líneas de fichero para obtener una línea de la imagen. Este es el modo en el que funciona la tarjeta EGA ( o la VGA en modo EGA) por lo que la línea se escribirá tal y como se lee del fichero. En las imágenes de 256 colores, el número de planos es ocho. Cada línea de la imagen viene codificada por planos de la forma siguiente: Línea 0: 000... 2────────────────────0 Plano 0 111... 2────────────────────0 Plano 1 222... . 333... . 444... . 555... . 666... . 777... 2────────────────────0 Plano 7 ││└───────────────0 3er pixel de la línea 0 │└────────────────0 2º pixel de la línea 0 └─────────────────0 1er pixel de la línea 0 Línea 1: 000... 2────────────────────0 Plano 0 111... 2────────────────────0 Plano 1 222... . 333... . 444... . 555... . 666... . 777... 2────────────────────0 Plano 7 ││└───────────────0 3er pixel de la línea 1 │└────────────────0 2º pixel de la línea 1 └─────────────────0 1er pixel de la línea 1 Por lo que, cada línea leída del fichero, deberá ser transformada, tomando para formar cada pixel un bit de cada plano, hasta 8, como indica la figura anterior. 2. Los ficheros IMG no poseen paleta de colores por lo que hay que asignarles una paleta por defecto, normalmente se les aplica una paleta de grises.5.5 EL FORMATO BMP (WINDOWS) GENERALIDADES SOBRE FICHEROS BMP El formato BMP es el estándar usado por Windows 3.X como fichero de intercambio de bitmaps. CARACTERISTICAS DE LOS FICHEROS BMP Los ficheros BMP pueden ser en la actualidad de tres tipos: Monocromos, 16 colores y 256 colores. No poseen ningún método de compresión, aunque existe una versión posterior conocida como RLE que sí lo usa. ESTRUCTURA DE UN FICHERO BMP Estos ficheros poseen una cabecera de 56 bytes. A diferencia de otros formatos como PCX, IMG, TGA, etc, los campos de la cabecera son casi siempre enteros de 4 bytes. Tras ella puede aparecer una paleta de colores de longitud variable. Para cada color de la paleta, aparecen cuatro bytes que definen los niveles de Azul, Verde, Rojo e Intensidad. Por último aparece la imagen codificada línea a línea sin comprimir. Para cada pixel de la imagen se requieren 1, 4 u 8 bits, según el número de colores. CABECERA La cabecera de un fichero BMP presenta la siguiente estructura: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 2 tipo Tipo de fichero, cte = "BM" 2 4 longitud Longitud del fichero en bytes 6 4 reservados Reservados, no se usan 10 4 inicio Posición del fichero donde empieza la imagen 14 4 tam Cte = 40 18 4 ancho Ancho en pixels 22 4 alto Alto en pixels 26 2 planos Numero de planos, cte = 1 28 2 bitspixel Bits por pixel: 1: Imagen monocroma 4: 16 colores 8: 256 colores 32 4 compresión Indica compresión. Cte = 0, no compr. 36 4 tamimagen Tamaño de la imagen, no se usa 40 4 x Extremo izquierdo, suele ser cero 44 4 y Extremo superior, suele ser cero 48 4 colores Indica la presencia o no de paleta 52 4 usados No se usa El primer campo de la cabecera (tipo) es una cte que identifica los ficheros BMP. El segundo (longitud) indica la longitud total del fichero en bytes. El tercero (reservado es un campo reservado. El cuarto (inicio) indica la posición en la que empiezan los datos de la imagen. El siguiente (tam) es una cte = 40. Los dos siguientes (ancho y alto) indican las dimensiones de la imagen. A continuación aparecen los planos por pixel (planos) y los bits por pixel (bitspixel). El siguiente (compresión) indica si la imagen está comprimida o no. Esta versión no admite compresión. A continuación aparece el tamaño de la imagen en pixels (tamimagen). Los dos siguientes (x e y) indican en extremo superior izquierdo de la imagen. El penúltimo campo (colores) indica la existencia de una paleta de colores. Si vale 0, hay paleta. El ultimo campo (usados) se ignora. CODIFICACION Como se ha indicado anteriormente, no se usa ningún criterio de compresión aunque la información no se encuentra codificada de la misma forma para cada tipo de fichero. Para los ficheros monocromos, se usa un bit por pixel. 010110 ... ││└───────────────0 3er pixel │└────────────────0 2º pixel └─────────────────0 1er pixel Para los de 16 colores, 4 bits por pixel. 11010010 ... ││││└┴┴┴────────0 2º pixel └┴┴┴────────────0 1er pixel Para los de 256 colores, 8 bits por pixel.5.6 EL FORMATO TGA (TARGA) La extensión TGA, se corresponde con los ficheros TARGA, un formato definido por TrueVision. Este formato es utilizado por un elevado número de aplicaciones para almacenamiento e intercambio de imágenes y no sólo en el ámbito de los PCs, también es usado por otras plataformas especializadas en el tratamiento de gráficos. CARACTERISTICAS DE LOS FICHEROS TGA Las imágenes que usan este formato varían desde las monocromáticas hasta las de 24 o 32 bits de profundidad de color. Los ficheros TGA pueden estar o no comprimidos. En el segundo caso, el método de codificación usado se denomina RLE. AMBITO DEL ESTUDIO Los ficheros TGA objeto del estudio son los monocromáticos y de mapa de color (hasta 256 colores) sin codificar. ESTRUCTURA DE UN FICHERO TGA Los ficheros TGA poseen una cabecera de 18 bytes. Tras la cabecera aparece, si existe, la paleta de colores que en lugar de estar codificada en formato RGB, aparece invertida (BGR). A continuación aparece la imagen que puede venir codificada en la forma RLE. Opcionalmente los ficheros TGA pueden incluir un área de desarrollador, un área de extensión, una tabla de corrección de colores y un pie. Estas áreas son usadas para ampliar la información de la imagen. No serán incluidas en el estudio del formato por ser meramente informativas. CABECERA BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 1 longitud Longitud del campo de identificación de la imagen, que se encuentra en el byte 10+cabecera 1 1 mapa_color Presencia o no de paleta de colores 2 1 tipo_imagen Tipo de imagen: 0: No hay datos 1: Mapa de color, sin comprimir 2: Color real, sin comprimir 3: B/N, sin comprimir 9: Mapa de color, compresión RLE 10: Color real, compresión RLE 11: B/N, compresión RLE 3 2 indice_mapa Indice a la paleta de colores 5 2 entradas_mapa Nº entradas de la paleta 7 1 tam_color Tamaño de cada definición de color (8,24 o 32) 8 2 inf_izda_hor Columna esquina inferior izquierda 10 2 inf_izda_ver Fila esquina inferior izquierda 12 2 ancho Anchura en pixels de la imagen 14 2 alto Altura en pixels de la imagen 16 1 prof_color_pixel Profundidad de color por pixel 17 1 orden bits 7, 6 = 0 bits 5, 4: orden de transferencia 00: inferior izquierda 01: inferior derecha 10: superior izquierda 11: superior derecha bits 3 a 0: nº bits de atributos por pixel El primer byte (longitud) contiene la longitud del campo de identificación de la imagen, que se encuentra en el byte 10+cabecera. El segundo (mapa_color) indica la presencia (1) o no (0) de paleta de color. El tercero (tipo_imagen) indica el tipo de la imagen. Se refiere a si la imagen es monocromática, de mapa de colores (RGB) o de color real (True Color). Además indica si la imagen está comprimida o no. A continuación un entero de dos bytes (indice_mapa) indica, en caso de existir, el lugar del fichero en el que se encuentra la paleta de colores. Tras este, otro entero (entradas_mapa) indica el número de colores que tiene la paleta. El séptimo byte (tam_color) indica el tamaño en bits de cada definición de color. A continuación dos enteros de dos bytes (inf_izda_hor y inf_izda_ver) indican las coordenadas x e y de la esquina inferior izquierda de la imagen. Otros dos enteros (ancho y alto) indican el tamaño en pixels de la imagen. A continuación un byte indicador de la profundidad de color por pixel (prof_color_pixel). Esto representa el número de bits requeridos para representar el color de un pixel. El último byte de la cabecera (orden) agrupa tres informaciones: Los bits 7 y 6 deben valer cero (0). Los bits 5 y 4 indican el orden en el que los pixels deberán ser transferidos a la pantalla, para ello se establece el siguiente patrón: 00 : Inferior izquierda 01 : Inferior derecha 10 : superior izquierda 11 : superior derecha Los bits 3 a 0 indican el número de bits de atributos por pixel. LA PALETA DE COLORES Se trata de tantos triples BGR como colores tenga la imagen. La presencia de la paleta viene determinada por el byte 1 de la cabecera. CODIFICACION Los ficheros capaces de ser leídos por la aplicación son los monocromos y los de hasta 256 colores (24 bits de tamaño de color y 8 bits de profundidad de color por pixel) sin codificar. Así pues, para la lectura de los datos de la imagen, basta con leer línea a línea el número de bytes requeridos para cada una de ellas. 5.7 EL FORMATO GIF (Graphics Interchange Format) GENERALIDADES SOBRE LOS FICHEROS GIF El formato GIF fue desarrollado en 1987 por Compuserve, creándose entonces la versión 87a. En 1989 se añadieron unas extensiones al formato dando lugar a la versión 89a. CARACTERISTICAS DE LOS FICHEROS GIF Los ficheros GIF permiten almacenar imágenes de hasta 256 colores. Pueden incluirse varias imágenes en un solo fichero, así como información relativa a las mismas. Lo más destacable de este formato es el grado de compresión que puede llegar a obtenerse gracias al uso de una versión modificada del algoritmo LZW. AMBITO DEL ESTUDIO En este estudio, se han implementado las rutinas necesarias para visualizar cualquier tipo de fichero GIF, reconociendo las extensiones de la versión 89a. Esta extensiones no son tratadas. También se incluyen las rutinas de compresión (desarrollada en ensamblador) y escritura de imágenes GIF. ESTRUCTURA DE UN FICHERO GIF La estructura general es la siguiente: ┌────────────────────────┐ │ Identificador GIF │ ├────────────────────────┤ │Descriptor de pantalla │ ├────────────────────────┤ │Paleta de color global │ ├────────────────────────┤ │Extensión (0 o varias) │ ├────────────────────────┤ │Descriptor de la imagen │ ├────────────────────────┤ │Paleta de color local │ ├────────────────────────┤ │Datos imagen (LZW) │ ├────────────────────────┤ │ . │ │ . │ │ . │ ├────────────────────────┤ │Extensión (0 o varias) │ ├────────────────────────┤ │Descriptor de la imagen │ ├────────────────────────┤ │Paleta de color local │ ├────────────────────────┤ │Datos imagen (LZW) │ ├────────────────────────┤ │Marca de fin de fichero │ └────────────────────────┘ El identificador de fichero GIF es una cadena de 6 caracteres cuyo contenido es 'GIF87a' o 'GIF89a' dependiendo de la versión. Para leer el fichero es bastante detectar los 3 primeros bytes. Los campos descriptor de pantalla y la paleta de color global se conocen como datos globales. Hacen referencia al dispositivo donde se crea o visualiza la imagen. Las extensiones son comentarios acerca de las imágenes. Pueden omitirse. Se añadieron en el año 1989, dando así lugar a la versión 89a, última conocida hasta el momento. Los campos descriptor de imagen, paleta local y datos son los llamados datos locales y son los que se repiten en caso de que existan múltiples imágenes en el fichero GIF Por último la marca de fin de fichero es el carácter punto y coma (;). DATOS GLOBALES El descriptor de pantalla es un conjunto de campos cuya estructura se muestra a continuación: ┌────────────────────────┐ │Ancho de pantalla │ ├────────────────────────┤ │Alto de pantalla │ ├────────────────────────┤ │Registro de flags local │ ├────────────────────────┤ │Color de fondo │ ├────────────────────────┤ │Byte 0 │ └────────────────────────┘ Los datos del descriptor se organizan del siguiente modo: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 2 ancho_pantalla Ancho de la pantalla 2 2 alto_pantalla Alto de la pantalla 4 1 bandera_global Registro formado por varias banderas o flags: Bits 0 a 2 (pixel). Bit 3: Reservado. Bits 4 a 6 (cr). Bit 7 (M). 5 1 color_fondo Color de fondo 6 1 cero No usado. Debe ser cero Los dos primeros campos (ancho_pantalla y alto_pantalla) definen la resolución en pixels de la pantalla. El tercer campo (bandera global) es un registro de 8 bits que hace referencia al color. Bits 0 a 2 (pixel): Incrementados en 1, indican el número de bits por pixel.Además 1 << (bits por pixel) indica el número de colores. Bit 3: Reservado debe ser cero. Bits 4 a 6 (cr): Incrementados en 1, indican el numero de bits por color. Bit 7 (M): Si es 0, no hay paleta global Si es 1, hay paleta global El cuarto campo (color_fondo) se usa como color de fondo. El último byte (cero) no se usa. Si existe la paleta de color global, ésta viene codificada en triples RGB de tres bytes, uno para cada componente. Existirán tantos triples como colores tenga la imagen. EXTENSIONES Como se ha dicho anteriormente, las extensiones son bloques meramente informativos acerca de la(s) imagen(es) contenidas en el fichero. Su presencia no es obligatoria y puede eludirse su tratamiento. Existen cuatro tipos de extensiones (control, comentarios, texto y aplicación) y todas ellas utilizan la misma estructura: Identificador: es una constante de un byte. Identifica el comienzo de una extensión. Su valor es (!). Tipo: es un byte que indica el tipo de extensión. Longitud: otro byte que indica el número de bytes que ocupa la extensión. Datos: Son tantos bytes como indique el campo longitud. Contiene la información. Fin: Byte de terminación de la extensión, siempre cero.Extensiones de control. Se utilizan para controlar la visualización de ficheros con múltiples subimágenes y se aplican únicamente a la primera de ellas, indicando al programa visualizador si debe esperar después de mostrar la primera subimagen. La extensión debe localizarse antes de la subimagen. Su estructura es la siguiente: Identificador: es una constante de un byte. Identifica el comienzo de una extensión. Su valor es (!). Tipo: Tipo de extensión. F9 en hexadecimal. Longitud: 4. Banderas: Un registro de 8 bits: Bits 5 a 7: reservados, deben ser cero. Bits 2 a 4: indican como borrar la imagen. Hay cuatro valores posibles: 00: no hay método específico. 01: dejar la imagen en pantalla. 10: Borrarla con el color de fondo. 11: Borrar y dejar la imagen previa. Bit 1: si es 1, esperar evento (pulsación de tecla o clic de ratón) para borrar la imagen. Bit 0: Si es uno, usar índice de transparencia. Retraso: valor de 16 bits que indica el retardo en centésimas de segundo que debe esperar el visor antes de borrar la imagen. Puede usarse junto con el bit uno del registro banderas. Transparencia. Byte que indica el índice de transparencia. Si el bit 0 del registro de banderas vale 1, el color indicado por este byte no debe dibujarse en pantalla, dejando lo que había antes de mostrar la imagen. Fin: Byte de terminación de la extensión, siempre cero. Extensiones de comentarios. Se usan para añadir información textual a los archivos. Informan sobre el autor, el título, etc. Es un texto ASCII que puede incluir retornos de carro. Su estructura es la siguiente: Identificador: es una constante de un byte. Identifica el comienzo de una extensión. Su valor es (!). Tipo: Tipo de extensión. FE en hexadecimal. Texto: Bloques de texto de longitud 1 a 255 bytes, precedidos de un byte que indica la longitud del bloque. Fin: Byte de terminación de la extensión, siempre cero. Extensiones de texto. Se usan para añadir textos a las imágenes. El visor debe tener la capacidad de dibujar los textos en modo gráfico. Se suponen los caracteres del mismo ancho. Su estructura es: Identificador: es una constante de un byte. Identifica el comienzo de una extensión. Su valor es (!). Tipo: Tipo de extensión. 01 en hexadecimal. Longitud: 12. X0: Esquina izquierda donde comienza el texto. 2 bytes. Y0: Esquina superior donde comienza el texto. 2 bytes. AnchoTexto: Ancho del rectángulo en pixels. 2 bytes. AltoTexto: Alto del rectángulo en pixels. 2 bytes. AnchoCaracter: Ancho de cada carácter en pixels. 1 byte. AltoCaracter: Alto de cada carácter en pixels. 1 byte. ColorTexto: Un byte, indica el color del texto. ColorFondo: Un byte, indica el color de fondo del texto. Texto: Bloques de texto de longitud de 1 a 255 bytes, precedidos de un byte que indica la longitud de cada bloque. Fin: Byte de terminación de la extensión, siempre cero. Extensiones de aplicación. Informan específicamente sobre la aplicación que creó el fichero. Su estructura es: Identificador: es una constante de un byte. Identifica el comienzo de una extensión. Su valor es (!). Tipo: Tipo de extensión. FF en hexadecimal. Longitud: 11. IdAplicacion: 8 bytes que contienen una cadena de 8 caracteres que identifican la aplicación que creó el GIF. Código: Código de comprobación de la autenticidad de la aplicación. Cada aplicación debe proveer un algoritmo que genere o compruebe el código. Tiene 3 bytes de longitud. Datos: Datos de la aplicación, dependen de cada una. Fin: Byte de terminación de la extensión, siempre cero. DATOS LOCALES El bloque descriptor de la imagen presenta la siguiente estructura: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 1 coma Cte = carácter coma (,) 1 2 x0 Coordenada izquierda de inicio de la imagen 3 2 y0 Coordenada superior de inicio de la imagen 5 2 ancho Ancho de la imagen 7 2 alto Alto de la imagen 9 1 bandera local Registro formado por varias banderas o flags: Bits 0 a 2 (pixel) Bits 3 a 5: Reservados deben valer 0. Bit 6: (I) Bit 7: (M) El ultimo campo (bandera local) es un registro de 8 bits que hace referencia al color y al orden de las líneas. Bits 0 a 2 (pixel): Incrementados en 1, indican el número de bits por pixel. Además 1 << (bits por pixel) indica el número de colores. Bits 3 a 5: Reservados, deben ser cero. Bit 6 (I): Si es cero, las líneas son consecutivas. Si es uno, están en modo entrelazado. Bit 7 (M): Si es 0, no hay paleta local, usar la global. Si es 1, hay paleta local. Si existe la paleta de color local, ésta viene codificada en triples RGB de tres bytes, uno para cada componente. Existirán tantos triples como colores tenga la imagen. Los datos de la imagen vienen comprimidos por el método LZW, que se explica más adelante, en el apartado codificación. La imagen puede estar dispuesta de modo secuencial, esto es, una línea tras otra o bien en modo entrelazado. En el modo entrelazado las líneas vienen dispuestas de la siguiente manera: Las primeras líneas del fichero se corresponden con las líneas 8, 16, 24, 32,... (en incrementos de 8) hasta completar la imagen. A continuación se encuentran las líneas 5, 13, 21,... (incrementos de 8) hasta completar la imagen . En tercer lugar se disponen las líneas 3, 7, 11,... (en incrementos de 4) hasta el final. Por último se encuentran las líneas 2, 4, 6,... (en incrementos de 2). Así pues, el proceso para visualizar las imágenes se dividirá en cuatro pasos. En el siguiente ejemplo se muestran, para una imagen de 16 líneas, las correspondencias entre las líneas del fichero y el lugar que ocupan en la pantalla, así como el paso en el que son llevadas a la pantalla: Lín.fichero Lín.imagen Paso 1 1 1 2 9 4 3 5 3 4 10 4 5 3 2 6 11 4 7 6 3 8 12 4 9 2 1 10 13 4 11 7 3 12 14 4 13 4 2 14 15 4 15 8 3 16 16 4 En la implementación realizada, debido a la gestión de memoria usada, no se siguen estos cuatro pasos, es más rápido llevar cada línea de fichero a su posición en la pantalla en cuanto es descomprimida.CODIFICACION COMPRESION DE FICHEROS GIF Los ficheros GIF usan una versión modificada del algoritmo de compresión LZW usado por programas de dominio público de compresión de ficheros tales como ARC, PKARC o PKZIP. Este método divide la imagen en pequeños paquetes, cada uno de un determinado tamaño. El final de la imagen se indica con un paquete que contiene cero bytes de datos. Cada paquete consiste en un "byte índice" seguido de hasta 255 bytes de datos comprimidos. El byte índice indica cuantos bytes contiene el paquete. Si el índice de un paquete es 255, el paquete tendrá una longitud total de 256 bytes. El ultimo paquete será un byte índice con valor cero. Para reducir el tamaño de los datos, el algoritmo convierte las líneas de datos en series de tokens o códigos que ocuparán menos espacio que los datos originales. El algoritmo maneja tres elementos mientras trabaja: - Los datos de entrada, llamado stream de caracteres. - Los tokens o códigos de salida, llamado stream de código. - La tabla de strings, usada para la conversión entre los dos anteriores elementos. Un fichero GIF es codificado con hasta 12 bits de compresión. Estos doce bits permiten representar valores desde 0 hasta 4096, por lo que la tabla de strings contendrá como máximo este número de entradas. Asumiendo que la imagen pueda tener 256 colores, el proceso de compresión se iniciará inicializando las 256 primeras posiciones de la tabla con los valores del 0 al 255. Estos valores representan entradas únicas e indivisibles de la tabla y el valor de cada entrada coincidirá con su localización en la tabla. Ninguna de las siguientes entradas tendrá esta propiedad. Una vez hecho esto, el programa buscará el primer carácter de la entrada (el stream de caracteres) en la tabla. Para ello usará dos buffers: El prefijo actual y el string actual. Ambos están vacíos al comienzo. El string actual se define siempre como el prefijo actual más el siguiente carácter del stream de caracteres. Cuando el programa coge el primer carácter del stream, el string actual es igual al prefijo, que está vacío, más el carácter. En definitiva, la primera vez el string es igual al primer carácter. El programa busca entonces el string en la tabla. Por definición, este string debe estar presente en la tabla, ya que esta última ha sido inicializada con todos los posibles valores de un byte. Por ello, el programa copiará el string en el prefijo y repetirá el proceso, añadiendo el siguiente carácter del stream al string. Ahora el string tendrá dos bytes de longitud. El programa buscará este nuevo string en la tabla sin encontrarlo, ya que no existen entradas de dos bytes. En ese momento se creará una nueva entrada en la tabla con el valor del string. Esta entrada será la 256, ya que desde la 0 a la 255 estaban ya ocupadas. Tras esto se envía el número 256 al stream de códigos (la salida). El proceso se repetirá hasta que todos los datos de la entrada sean procesados. Hay que hacer dos adiciones para los ficheros GIF: - La primera de ellas es que, cada cierto tiempo, un código especial de borrado es enviado. Esto indica al decodificador que reinicialice su tabla de strings. Se ha de enviar cuando el codificador decide que la tabla está llena. Este código se define como el número máximo de colores de la imagen (256 en este caso). - La segunda es un código de final de imagen y se define como uno más que el código de borrado. Si una imagen tiene 200 líneas, el codificador enviará a la salida 201, empezando la última línea con éste código y sin contener datos. Debido a estos dos códigos extra, la adición de nuevos códigos a la tabla se realizará desde las dos siguientes posiciones al último código inicializado en la misma. DESCOMPRESION DE FICHEROS GIF Para realizar la descompresión o decodificación de un fichero GIF, el stream de caracteres se convierte en la salida y el stream de códigos se constituye como entrada. Igualmente el programa usará una tabla de strings que se inicializa al principio con los posibles valores. Se definen el código actual y el código anterior. El código actual comienza siendo el primer código de entrada del stream de códigos. El programa empieza buscando el primer código en la tabla y lo encontrará. Mandará el string de la tabla al stream de caracteres y copiará este código en el código anterior. Ahora tomará el primer carácter del string que ha enviado a la salida y lo añadirá al prefijo actual. La primera vez el prefijo contiene sólo este carácter. Añadirá este string a la tabla y copiará el código anterior en el actual. Este proceso se repetirá. En algún momento, el programa tomará un código del stream que no esté en la tabla, al igual que el programa codificador tomó un string que no estaba en la tabla durante el proceso de compresión. Este código deberá ser el siguiente en la tabla, después de todos los conocidos. Como el primer carácter de este string ya está en la tabla, el programa trabajará ahora con el contenido del nuevo string, representado por este nuevo código y formado por el string anterior más un carácter nuevo. 6 ESTRUCTURAS DE DATOS. REPRESENTACION DE LAS IMAGENES. Este capítulo está dedicado a la estructura de datos usada para el almacenamiento de las imágenes en memoria así como a la representación de las imágenes en función del tipo de memoria usada para su almacenamiento y el modo de video usado para su visualización. Es sin duda el capítulo más importante, ya que todas las operaciones realizadas sobre las imágenes la estructura y modos de almacenamiento y visualización explicados a continuación. 6.1 LA ESTRUCTURA DE DATOS. La estructura de datos para el almacenamiento temporal de la imagen en memoria introducida en el capítulo 4 debe cubrir todas las necesidades requeridas para la definición de una imagen. Debe ser capaz de guardar la imagen y la información relativa a ella, pero siempre desde una óptica objetiva, evitando vincularla a ningún formato gráfico concreto. Partiendo de estas premisas, la aplicación define la siguiente estructura estándar de la imagen: ┌──────────┐ │Cabecera │ ├──────────┤ │Imagen │ └──────────┘ Obsérvese el paralelismo entre la estructura adoptada y la práctica totalidad de los formatos gráficos que se estudian en esta obra. La cabecera estándar de la imagen posee los siguientes campos: BYTE TAMAÑO CAMPO DESCRIPCION Y CONTENIDO 0 80 nombre Nombre del fichero en el disco 80 2 formato Formato gráfico de origen 82 2 modo Modo gráfico de visualización 84 2 ancho Ancho en pixels de la imagen 86 2 alto Alto en pixels de la imagen 88 2 colores Número de colores de la imagen 90 2 bytes Bytes por línea 92 1 haypaleta Campo lógico que indica la presencia o no de paleta de colores propia de la imagen 93 132 mem Gestor de memoria de los datos de la imagen 225 768 paleta Paleta de 256 colores El primer campo (nombre) es una cadena de 80 caracteres que almacena el nombre del fichero en el disco. El segundo (formato) es un entero que indica el formato original de la imagen: 0 : MACPAINT. 1 : PCX. 2 : GIF. 3 : TIFF. 4 : IMG. 5 : TGA. 6 : BMP. 7 : OTRO. El tercer campo (modo) indica el modo gráfico en el que la imagen debe ser visualizada. El modo está en consonancia con la manera en que la imagen se almacena en la memoria como bitmap. Los modos son: 0 : VIDEOmono. Mapa de bits monocromo. 1 : VIDEOega. Mapa de bits 16 colores. 2 : VIDEOvga. Mapa de bits 256 colores. Los dos siguientes enteros (ancho y alto) indican las dimensiones de la imagen en pixels. A continuación (colores) se indica el número de colores o grises de la imagen. El séptimo campo (bytes) indica el número de bytes requerido para almacenar una imagen. Para imágenes monocromáticas, se requiere un bit por cada pixel. Para imágenes EGA, 4 bits por pixel. Las imágenes VGA requieren un byte por pixel. El octavo campo (haypaleta) es un byte que indica si existe o no paleta de colores. 0 : Sin paleta. 1 : Con paleta. El siguiente campo (mem) es un gestor de la memoria en la que se encuentra la imagen. Ya se adelantó en el capítulo 3 que el programa almacena los datos de la imagen usando tres posibles modelos de memoria: EMS, XMS y 'memoria virtual' (que llamaremos VMS). El campo mem de la cabecera admite tres posibles contenidos según la memoria que esté usando el programa: Para EMS, el campo contiene: tabla: puntero de tipo entero a una tabla de líneas*2 enteros que guarda, para cada línea de la imagen, la página de memoria EMS y el desplazamiento dentro de la página donde se encuentra almacenada la línea. gestor: entero usado como manejador de memoria EMS. Para XMS: un entero, que es el manejador de memoria XMS. Para VMS o 'memoria virtual': gestor: Es un puntero al fichero del disco usado como 'memoria virtual'. fichero: Cadena de 128 caracteres en la que se guarda el nombre del fichero de 'memoria virtual'. La gestión de los distintos tipos de memoria para el almacenamiento de las imágenes se detalla más adelante en el apartado de representación de las imágenes según el tipo de memoria. El último campo (paleta) almacena una paleta de colores (si existe) de 2 a 256 colores. Cada color se guarda con tres bytes, uno para cada componente RGB. 6.2 REPRESENTACION DE LAS IMAGENES. Una vez vista la estructura diseñada para guardar las imágenes se procederá a describir como se van a almacenar éstas en la memoria. Este estudio se va ha realizar desde dos puntos de vista completamente diferentes: El primero de ellos es el modo de almacenamiento de la imagen según el tipo de memoria utilizado. El segundo es el modo de almacenamiento según el modo de visualización usado. 6.2.1 SEGUN EL TIPO DE MEMORIA. Existen cuatro procesos comunes para el almacenamiento de las imágenes sea cual sea la memoria utilizada. 1. Reservar memoria. Todas las imágenes necesitan reservar un área de memoria en la que alojarse. La cantidad de memoria a reservar dependerá del tamaño que ocupe la imagen. Este proceso es imprescindible, y debe realizarse antes que ningún otro. Si no hay espacio suficiente para albergar la imagen, ésta no podrá ser procesada. El hecho de reservar memoria para la imagen lleva consigo el conocer el lugar reservado para la imagen. 2. Escribir imagen en memoria. Consiste en el almacenamiento de la imagen en el área reservada para ella. Esta escritura se realizará línea a línea desde un buffer de memoria convencional. La escritura de cada línea en el lugar adecuado será posible gracias al paso previo de localización y reserva del espacio de la imagen, que permite conocer el lugar donde se alojará la línea. 3. Leer imagen desde la memoria. Es el proceso contrario al anterior. La lectura se realizará línea a línea desde la memoria a un buffer temporal. La lectura de la línea adecuada es posible gracias al proceso previo de reserva de espacio, que permite conocer el lugar donde se aloja la línea. 4. Liberar memoria. Una vez que la imagen ha sido tratada con algún fin, debe procederse a la liberación de la memoria reservada previamente, con objeto de que ese espacio quede disponible para ser usado por una nueva imagen. La omisión de este proceso dará lugar a la imposibilidad de cargar nuevas imágenes. A continuación se detallan estos cuatro procesos para cada uno de los tres tipos de memoria utilizados. 6.2.1.1 MEMORIA EMS. 1. Reservar memoria. Cuando se trata de memoria EMS, la reserva de memoria para la imagen consiste en calcular el número de páginas EMS necesario para guardar la imagen y, reservarla. Además, se reserva memoria convencional para crear una tabla de dos dimensiones en la que se guarda la posición de cada línea en la memoria EMS. La tabla contiene para cada línea el número de página y el desplazamiento dentro de ésta. La reserva de memoria EMS se hace a través de un servicio de la interrupción 67H, con lo que se obtiene un gestor de memoria que permite diferenciar entre la memoria que se ha reservado ahora y la que pudieran estar usando otros procesos. Una vez más debe insistirse en la necesidad de que el driver de memoria EMS debe haber sido previamente instalado[14]. En la aplicación, se usa el EMM386.EXE suministrado con el DOS. En el disquete del programa se incluye el fichero CONFIG.EMS que puede ser renombrado como config.sys para ejecutar el programa usando memoria EMS. 2. Escribir imagen en memoria. La escritura de las líneas de la imagen se realiza escribiendo en la página adecuada el buffer de la línea. La página y el desplazamiento se encuentran en la entrada de la tabla correspondiente a la línea a escribir. Si la página no se encuentra en el marco de página EMS, se realiza el proceso de mapeado de páginas físicas y lógicas y, la página correspondiente se situará en el marco de página. 3. Leer imagen desde la memoria. La lectura de las líneas de la imagen se realiza escribiendo en el buffer de la línea (en memoria convencional) la línea guardada en la memoria EMS. La página y el desplazamiento se encuentran en la entrada de la tabla correspondiente a la línea a leer. Si la página no se encuentra en el marco de página EMS, se realiza el proceso de mapeado de páginas físicas y lógicas y, la página correspondiente se situará en el marco de página. 4. Liberar memoria. El proceso de liberación de la memoria EMS conlleva la liberación de la memoria convencional ocupada por la tabla y la de la propia memoria EMS. Las operaciones relativas al manejo de memoria EMS se encuentran en el módulo de la aplicación del mismo nombre y son llamadas desde el módulo MEMORIA. 6.2.1.2 MEMORIA XMS. 1. Reservar memoria. Cuando se trata de memoria XMS, la reserva de memoria para la imagen consiste en calcular el número de bloques de 1Kb de XMS necesario para guardar la imagen y, reservarla. Al reservar la memoria XMS, se obtiene un gestor de memoria que permite diferenciar entre la memoria que se ha reservado ahora y la que pudieran estar usando otros procesos. No se requiere el uso de tabla alguna como en el caso de la memoria EMS, ya que la imagen se almacenará de forma continua. Las operaciones de transferencia de datos entre la memoria convencional y la XMS se realizan pasando al driver de memoria XMS un bloque de información con la siguiente estructura: CAMPO DESCRIPCION longitud Longitud a transferir en bytes fuente Manejador de memoria origen desp_fuente Desplazamiento de la memoria origen destino Manejador de la memoria destino desp_destino Desplazamiento de la memoria destino Al igual que en el caso de la memoria EMS, el driver de memoria XMS debe haber sido previamente instalado. En la aplicación, se usa el HIMEM.SYS suministrado con el DOS[14]. En el disquete del programa se incluye el fichero CONFIG.XMS que puede ser renombrado como config.sys para ejecutar el programa usando memoria XMS. 2. Escribir imagen en memoria. Para escribir una línea de la imagen en memoria extendida desde un buffer de memoria convencional, los campos de la estructura deben contener los siguientes valores: longitud: número de bytes de la línea. fuente: cero (0). desp_fuente: El puntero al buffer convertido a long. destino: manejador de memoria XMS. desp_destino: desplazamiento de la línea en la imagen. 3. Leer imagen desde la memoria. Para leer una línea de la imagen desde la memoria extendida a un buffer de memoria convencional, los campos de la estructura deben contener los siguientes valores: longitud: número de bytes de la línea. fuente: manejador de memoria XMS. desp_fuente: desplazamiento de la línea en la imagen. destino: cero (0). desp_destino: El puntero al buffer convertido a long. 4. Liberar memoria. El proceso de liberación de la memoria XMS se realiza con una llamada al driver de memoria extendida. Las operaciones relativas al manejo de memoria XMS se encuentran en el módulo de la aplicación del mismo nombre y son llamadas desde el módulo MEMORIA.6.2.1.3 MEMORIA VMS. 1. Reservar memoria. Cuando se trata de 'memoria virtual', la reserva de memoria para la imagen consiste en calcular el número de bytes necesario para guardar la imagen para, posteriormente, crear y abrir un fichero temporal del tamaño suficiente. La reserva conlleva la obtención de un puntero al fichero que será usado para la lectura y escritura de la imagen. 2. Escribir imagen en memoria. La escritura de una línea de la imagen se realiza calculando el desplazamiento de ésta dentro del fichero y moviendo el puntero del mismo hacia la posición correcta, escribiendo en ella la línea contenida en el buffer. 2. Leer imagen desde la memoria. La lectura de una línea de la imagen se realiza calculando el desplazamiento de ésta dentro del fichero y moviendo el puntero del mismo hacia la posición correcta, leyendo en el buffer desde dicha posición. 4. Liberar memoria. El proceso de liberación de la 'memoria virtual' supone el cierre y borrado del fichero temporal usado como 'memoria virtual'. Las operaciones relativas al manejo de 'memoria virtual' se encuentran en el módulo de la aplicación VMS y son llamadas desde el módulo MEMORIA. 6.2.2 SEGUN EL MODO DE VISUALIZACION. La manera en que los bytes se organizan para guardar una imagen en memoria varía según su número de colores y el modo de visualización de la misma. Las imágenes tratadas en este estudio pueden dividirse en tres tipos: - Monocromas, blanco y negro. 1 bit por pixel. - Hasta 16 colores. 4 bits por pixel. - Hasta 256 colores. 8 bits por pixel. Por otro lado los modos de visualización son también tres: - Monocromo, para imágenes de 2 colores (VIDEOmono). Se representan en un plano, con 1 bit por pixel. - EGA, para imagenes de hasta 16 colores (VIDEOega). Se representan en 4 planos, con 4 bits por pixel, uno por cada plano. - VGA, para imágenes de hasta 256 colores (VIDEOvga). Se representan en un plano, con ocho bits por pixel. Visto esto, puede construirse una tabla que permita conocer los modos posibles de visualización de cada imagen: MODO DE VIDEO MONOCROMO EGA VGA Monocroma SI SI SI Hasta 16 colores NO SI SI Hasta 256 colores NO NO SI Lógicamente y en relación al modo usado, lo ideal es guardar la imagen en memoria de manera que su visualización (y en general todas las operaciones a realizar sobre ella) sea lo más inmediata posible. Dicho esto, se describen ahora los tres modos de almacenamiento y visualización de las imágenes. 6.2.2.1 MODO MONOCROMO. Para guardar una imagen monocroma se precisa un bit para almacenar cada pixel. Si el bit correspondiente a un pixel es cero, el color será negro mientras que si el bit vale uno, el color será blanco. Las líneas se almacenarán secuencialmente, requiriéndose un número de bytes por línea suficiente para guardar 8 pixels en cada byte. Una línea monocroma será como sigue: 10111010 ... ││└─────────────── 3er pixel │└──────────────── 2º pixel └───────────────── 1er pixel La visualización de una imagen organizada de esta forma en el modo MONOCROMO es inmediata, basta con copiar la información tal y como está, en la memoria de vídeo. 6.2.2.2 MODO EGA. Para almacenar una imagen EGA de hasta 16 colores se precisan 4 bits para almacenar cada pixel. Esto es así porque con 24 combinaciones se obtienen las 16 tonalidades posibles. Los 4 bits que definen cada pixel se toman como un índice o entrada a la paleta de color. El color indicado en la paleta será el color del pixel. La memoria de vídeo en el modo EGA se organiza en cuatro planos, de manera que cada uno de los cuatro bits que forman un pixel deberá escribirse en el plano correspondiente. Para guardar una organización lo más acorde con el modo de operación EGA, las líneas también se almacenan secuencialmente, pero en esta ocasión cada línea se divide en cuatro partes. Cada una guarda un bit de cada pixel, el correspondiente a cada plano. En realidad una línea EGA estará formada por cuatro sublíneas consecutivas, cada una de las cuales contiene la información de cada plano. Así la primera sublínea pertenece al primer plano, la segunda al segundo plano y así para las cuatro sublíneas. Cada línea se almacena como sigue: 1ª sublínea, guarda los bits para el 1er plano 011010 ... ││└─────────────── 1er bit del 3er pixel │└──────────────── 1er bit del 2º pixel └───────────────── 1er bit del 1er pixel 2ª sublínea, guarda los bits para el 2º plano 111000 ... ││└─────────────── 2º bit del 3er pixel │└──────────────── 2º bit del 2º pixel └───────────────── 2º bit del 1er pixel 3ª sublínea, guarda los bits para el 3er plano 010110 ... ││└─────────────── 3er bit del 3er pixel │└──────────────── 3er bit del 2º pixel └───────────────── 3er bit del 1er pixel 4ª sublínea, guarda los bits para el 4º plano 100100 ... ││└─────────────── 4º bit del 3er pixel │└──────────────── 4º bit del 2º pixel └───────────────── 4º bit del 1er pixel Para visualizar las imágenes organizadas de esta manera en el modo EGA, se procederá a escribir cada sublínea en su plano correspondiente, con el debido desplazamiento dentro de éste según la línea de que se trate.6.2.2.3 MODO VGA. Para almacenar una imagen VGA de hasta 256 colores se precisan 8 bits para almacenar cada pixel. Esto es así porque con 28 combinaciones se obtienen las 256 tonalidades posibles. Los 8 bits que definen cada pixel se toman como un índice o entrada a la paleta de color. El color indicado en la paleta será el color del pixel. Las líneas se almacenarán secuencialmente, requiriéndose un número de bytes por línea igual al número de pixels. Una línea VGA será como sigue: 1101001010111010... ││││││││└┴┴┴┴┴┴┴ 2º pixel └┴┴┴┴┴┴┴──────── 1er pixel La visualización de una imagen organizada de esta forma en el modo VGA es inmediata, basta con copiar la información tal y como está, en la memoria de vídeo. El hecho de poder representar una imagen en más de un modo de visualización requiere de un tratamiento a nivel de bits que transforme la imagen almacenada en la memoria. Las funciones para realizar estas transformaciones y gestionar todo lo relacionado con la tarjeta gráfica se encuentran en el módulo VIDEO.7 EL TRATAMIENTO DE LAS IMAGENES. Una vez conocida la organización de las imágenes en memoria, ha llegado el momento de conocer las distintas operaciones que la aplicación puede realizar sobre ellas. Para ello, se distinguen tres tipos de operaciones principales: conversión de formato, transformación e impresión. 7.1 CONVERSION DE FORMATOS. La conversión de una imagen entre formatos distintos requiere cargar en memoria la imagen grabada en el formato original para, posteriormente, visualizarla y grabarla de nuevo en disco con el formato de salida deseado. 7.1.1 CARGA DE IMAGENES. La carga de una imagen en cualquier formato implica primeramente detectar que efectivamente el fichero que guarda la imagen pertenece a dicho formato gráfico. El siguiente paso es reservar memoria para la cabecera estándar de la imagen (definida en el capítulo 6) y rellenarla de acuerdo con la información dada por el fichero. Posteriormente se reserva memoria para la imagen en sí (expandida, extendida o 'virtual'). Por último y de acuerdo con las especificaciones del formato se procede a la carga de la imagen desde el disco a la memoria. La imagen será almacenada usando uno de los tres modos gráficos explicados en el capítulo anterior. En ocasiones la imagen se encuentra codificada de forma distinta a como se almacena en memoria y muchas veces comprimida para ocupar menos espacio en disco. Es tarea de cada uno de los módulos dedicados a cada formato el decodificar y/o descomprimir la imagen para adecuarla al modo de almacenamiento y visualización usado. 7.1.2 VISUALIZACION DE IMAGENES. La visualización de la imagen es un proceso inmediato a la carga de la misma en la memoria. Ya se ha visto en el capítulo 6 como se organiza la memoria de vídeo para actuar de acuerdo al modo seleccionado. La visualización de la imagen tiene tres pasos: El primero consiste en la activación del modo gráfico en el que la imagen se va a visualizar. En segundo lugar, se precisa establecer la paleta de colores de la imagen como paleta del sistema. El último paso supone la lectura de los datos de la imagen desde la memoria de almacenamiento y su escritura en la memoria de pantalla. Es posible cambiar el modo de visualización de la imagen. Para ello se crea una nueva estructura en memoria y se reserva el espacio necesario para guardar la imagen resultante. El algoritmo para cambiar el modo de la imagen tomará como origen la imagen original y actuará sobre ella, escribiendo la imagen resultante en la nueva estructura. Una vez terminado el proceso, la imagen original será eliminada y liberada su memoria. En ocasiones el tamaño de la imagen puede superar el área de pantalla, por lo que se hace necesaria la implementación de un panning, técnica que consiste en mostrar un área de la imagen y permitir al usuario moverse sobre la imagen con las teclas del cursor. En realidad lo que se hace es pintar áreas parciales de la imagen en la pantalla tomando las coordenadas adecuadas según la tecla pulsada. El módulo VIDEO se encarga de todas las operaciones relacionadas con la visualización de las imágenes. 7.1.3 GRABACION DE IMAGENES. La grabación de una imagen en un formato determinado consiste en elaborar a partir de la cabecera estándar las estructuras propias de cada formato para especificar las características de la imagen en el fichero destino y, una vez hecho esto, esta información y los datos de la imagen se graban en el fichero. En ocasiones la imagen ha de codificarse de forma distinta a como se almacena en memoria y muchas veces comprimirse para ocupar menos espacio en disco. Es tarea de cada uno de los módulos dedicados a cada formato el codificar y/o comprimir la imagen. 7.2 TRANSFORMACION DE IMAGENES. Bajo el epígrafe de transformación de imágenes se van a tratar algunas operaciones que se pueden realizar sobre las mismas. Estas operaciones son: Escalado. Giro o Reflejo. Conversión a tonos de gris. Conversión a blanco y negro (dithering). Obtención de negativos. Escalado del número de colores. 7.2.1 ESCALADO DE IMAGENES. El escalado de una imagen consiste en la ampliación o reducción del tamaño de la misma. El escalado se realiza atendiendo a un factor de escalado. En la aplicación se define un factor de escala para el ancho y otro para el alto, de tal manera que la imagen puede reducirse o ampliarse en uno u otro sentido. Los factores se han definido del 0 al 200, de tal manera que un factor de 100 equivale a la imagen actual (100%). Si se emplea un factor superior a 100, la imagen será ampliada. Por el contrario, si el factor es inferior a 100, la imagen será reducida. Por poner algún ejemplo, si usamos un factor de 50 para el ancho y el alto, la imagen se verá reducida a la mitad. Si se emplea un factor de 170 para el ancho y de 100 para el alto, la imagen se 'estirará' a lo ancho. Para escalar una imagen se calcula en primer lugar la memoria necesaria para almacenar la imagen resultante y se reservan una nueva cabecera estándar y la memoria para albergar la imagen. La reducción consistirá en la eliminación del número de pixels necesario para la obtención de una imagen del porcentaje indicado en el factor de escala. Los pixels se multiplicarán por el factor dividido por 100. La ampliación consistirá en la repetición del número de pixels necesario para la obtención de una imagen del porcentaje indicado en el factor de escala. Los pixels se dividirán por el factor dividido por 100. El algoritmo de escalado tomará la imagen original y la transformará escribiendo los resultados en la nueva estructura. Una vez concluido el proceso, la imagen original será eliminada y liberada su memoria.7.2.2 REFLEJO DE IMAGENES. El reflejo de una imagen consiste en el intercambio de los pixels horizontal o verticalmente, como si de un espejo se tratara. Para ello no se requiere reservar espacio para la imagen destino, ya que la operación se realiza directamente sobre la imagen. El reflejo horizontal es un proceso sumamente sencillo cuando se trata de imágenes VGA, ya que basta con intercambiar los bytes de cada línea. El primero será el último, el segundo será el penúltimo, etc. Cuando se trata de imágenes monocromas además de cambiar los bytes de sitio, debe invertirse el orden de los bits de cada byte. Para imágenes EGA, deben cambiarse los bytes de sitio e invertirse los bits de cada byte para cada uno de los cuatro planos (las cuatro sublíneas) de la línea. El reflejo vertical es muy simple en todos los casos, basta con intercambiar el orden de las líneas. La primera será la última, la segunda será la penúltima, etc. Basta con leer de la memoria los pares de líneas y escribirlos cambiados de sitio.7.2.3 CONVERSION A GRIS Y A BLANCO Y NEGRO. Como ya se adelantó en el apartado 3.1.4 en lo relativo a la impresión de imágenes de color en dispositivos de blanco y negro, se exponen ahora las soluciones a esta problemática. Representar en blanco y negro una imagen de color puede parecer en un principio un problema insuperable; sin embargo, esto no es así, la fotografía, una de las tecnologías visuales más antiguas lo ha estado haciendo durante más de un siglo. Una fotografía en blanco y negro, reduce a tonos de grises la imagen en color. Otra técnica, la de la industria periodística, ha estado reduciendo las escalas de grises a fotograbados (halftones). Esta técnica consiste en representar cada color con un patrón de halftone, constituido por puntos blancos y negros. Esta técnica no resulta práctica a la hora de representar imágenes de una gama considerable de colores. Por ejemplo, para representar una imagen de 256 colores se requiere para cada pixel un área de 16x16 pixels (256 posibilidades). Si la imagen tuviese un tamaño de 320x200, daría lugar a otra de 5120x3200. Además, aparte de no conseguir una imagen de gran calidad, el software para generarla sería tremendamente pesado y lento. Existe otra técnica para transformar imágenes de color a blanco y negro: el dithering. El dithering es un proceso algorítmico de reducción de una imagen de color a una serie de puntos blancos y negros, de forma que la escala de grises de la imagen original se conserva en cierta medida. El dithering parece hacer lo imposible. Aplicando el dither adecuado a una imagen en color, se puede crear una imagen monocromática de las mismas dimensiones conservando lo que parece ser gran parte de la información de la escala de grises. 7.2.3.1 REDUCCION A TONOS DE GRIS. Cualquier imagen en color se puede reducir a otra de escala de grises sumando simplemente los colores aditivos primarios (rojo, verde y azul). La fórmula para hacerlo es como sigue: gris = 0.30*rojo + 0.59*verde + 0.11*azul Si se aplica esta fórmula a la paleta de colores de un fichero, bastará con sustituir cada una de las componentes RGB de cada color por el resultado obtenido, para obtener la imagen en tonos de gris. Aunque esto es todo lo que se necesita, los resultados pueden no ser muy adecuados. Es aconsejable 'remapear' las sombras de grises un poco, con lo que se consigue un mayor contraste de la imagen original. Remapear la escala de grises implica expandir el núcleo central de la escala. Aunque es posible hacerlo usando una función, se obtienen mejores resultados usando una paleta o mapa de grises. El valor del gris original de la fórmula anterior se utiliza como índice a la paleta de grises. En la aplicación se usa un mapa de 256 grises, cuyos valores han sido determinados por el método de tanteos. Pueden cambiarse los valores para obtener otros resultados. 7.2.3.2 APROXIMACION AL DITHERING. METODO BAYER. La manera más simple de crear una imagen monocromática a partir de un dibujo en color reducido a escala de grises es utilizar un umbral (threshold). Consiste simplemente en asignar un nivel arbitrario debajo del cual un pixel se considerará negro, y sobre el cual, se considerará blanco. Si se define el threshold a medio camino entre el blanco y el negro, partiendo de que el blanco sería 255, el threshold será 127. Cualquier pixel con un nivel de gris mayor que 127 quedará como blanco. El inconveniente de este enfoque es bastante obvio. Innumerables detalles de la imagen en color original desaparecen y el dibujo queda excesivamente contrastado. Pueden obtenerse otros resultados cambiando el valor del threshold, pero el gráfico final nunca será especialmente bueno. Una de las primeras formas de dithering usadas en microordenadores fue el 'pattern dithering'. El dither Bayer es uno de los más frecuentes. El principio de un dither Bayer es comparar las escalas de grises de la imagen original con un patrón o modelo fijo (dither pattern). Este modelo tiene una matriz de 8x8, de forma que la escala de grises se reduce a 64 niveles posibles. Una vez hecho esto, cada bloque de 8x8 de la imagen es comparado con el modelo. Los pixels de la imagen fuente que superen los elementos correspondientes en la matriz serán pixels blancos en la imagen destino. Los que no los superen, serán negros. 7.2.3.3 DIFUSION DE ERRORES. ALGORITMOS. El problema del método Bayer es que imprime un modelo muy rígido sobre las imágenes que procesa, sin tener en cuenta el contenido de la imagen. El modelo que el dither Bayer imprime en una imagen es conocido como 'artefacto' (artifact). Los artefactos son subproductos visuales no deseados del tratamiento de imagen. En dithering se pretende crear un proceso que produzca una ilusión fiable de continuas escalas de tonos grises sin artefactos visibles. El camino para llegar a ello es emplear la difusión de errores. Si, por ejemplo, se desea comparar un pixel de escala de grises con un threshold, cuyo valor es 127, y el pixel tiene un nivel de gris de 150, el pixel será blanco. Sin embargo hay un error de 23 (la diferencia entre el nivel de gris del pixel y el nivel del threshold). Si este error se expande a los pixels circundantes, los efectos serán menos evidentes en el dither final. Hay que tener en cuenta que estos pixels también tendrán errores. El resultado será constituir una serie de pixels blancos y negros que se parecerá mucho a la escala de grises original. El algoritmo más conocido en la difusión de errores es el filtro Floyd-Steinberg 1975. El filtro es el siguiente: X 7 3 5 1 La lectura de un esquema de difusión de error es más simple de lo que parece. Obsérvese que todos los números del esquema suman 16. Dado que hay un error entre el pixel en X y el threshold entre el blanco y el negro, se debe añadir 7/16 del error al pixel que está justo a la derecha de X; 3/16 al pixel que está a la izquierda de X y un pixel abajo; 5/16 al que está debajo de X y el 1/16 restante al que está una posición abajo y a la derecha de X. Una vez hecho esto, se selecciona el siguiente pixel de la imagen y se repite el proceso. Los resultados del filtro Floyd-Steinberg son bastante buenos. Se pueden mejorar usando un filtro que se comunique con un número mayor de pixels, extendiendo el error sobre más puntos. El filtro Stucki mejora los resultados del F-S, o mejor dicho, produce unos diferentes, ya que los resultados en dithering son siempre un poco subjetivos. El dither Stucki funciona como sigue: X 8 4 2 4 8 4 2 1 2 4 2 1 Los números suman 42, de forma que el pixel a la derecha de X obtendría un 8/42 del error y así sucesivamente. Su inconveniente es que es lento. El tercer filtro de dithering más comúnmente encontrado es el Burkes. Es un punto medio entre los dos anteriores. Se representa de la siguiente forma: X 8 4 2 4 8 4 2 Existen otros filtros con mayor difusión pero muy lentos para ser ejecutados en un microordenador. Así tenemos el filtro Sierra: X 5 3 2 4 5 4 2 2 3 2 El filtro Jarvice, Judice y Ninke: X 7 5 3 5 7 5 3 1 3 5 3 1 Y el filtro Stevenson & Arce: X 32 12 26 30 16 12 26 12 5 12 12 5 Para concluir con el dithering, simplemente decir que todo lo visto en este capítulo tan solo pretende introducir al lector un poco en el tema, ya que existen multitud de técnicas y variaciones acerca del mismo, y no solo en lo referente a dithering. Estas y otras técnicas (más elaboradas) se aplican a imágenes en colores para reducir el número de estos, difuminar, contrastar, etc. En esta aplicación se han implementado los algoritmos Floyd-Steinberg, Stucki y Burkes basados en la difusión de errores y el Bayer Pattern para reducir imágenes en color a blanco y negro. También se aplica el método de la fórmula para convertir las imágenes a tonos de gris. El módulo de la aplicación encargado de realizar estos procesos es COLOR.7.2.4 OBTENCION DE NEGATIVOS. Otra operación usada en el tratamiento de imágenes y que se añade a este estudio a modo de introducción es la obtención de negativos de imágenes. No es difícil intuir que el negativo de una imagen monocromática, se obtiene cambiando los pixels de color negro por blancos y viceversa. En realidad si se supone que el valor para el negro es 0 y para el blanco es 255, para convertir el blanco en negro, lo que se hace es restar a 255 el valor del blanco (también 255), dando como resultado 0 (negro). Haciendo la misma operación con el negro (restarlo a 255) se obtiene el blanco. Si en una paleta de gris se restan a 255 los valores de cada uno de los tonos de gris, se obtienen los tonos de la paleta invertida. El negativo de una imagen a color se basa en el mismo principio. Para convertir una imagen a color en su imagen negativa, se restan cada uno de los tres componentes de color (rojo, verde y azul) al valor 255, y se sustituye cada resultado en la paleta de colores. Para obtener el negativo de una imagen monocromática, se leerán todas las líneas de la imagen y se negarán todos sus bytes. Para obtener el negativo de una imagen EGA o VGA bastará con aplicar a la paleta las operaciones descritas anteriormente.7.2.5 ESCALADO DEL NUMERO DE COLORES. En la conversión de imágenes de color entre distintos formatos gráficos, se plantea en ocasiones el caso de que una imagen con un determinado número de colores se almacena con un número superior de colores que los que realmente tiene. Este es el caso por ejemplo de los ficheros PCX, en los que toda imagen de más de 16 colores, se almacena con una paleta de 256 tonalidades. Si se lee una imagen PCX de este tipo y se pretende convertir a una imagen BMP, en la que solamente se guarda una paleta con el número de colores usado, se grabará información de más en el fichero de salida, haciendo que éste ocupe más espacio en disco y que además no contenga una información acorde con la imagen que representa. No se pretende en este estudio mostrar las técnicas para la reducción de colores similar al dithering, ya que no es objetivo del mismo. Tan sólo se intenta que cada imagen guarde el número correcto de colores que contiene. Esto no siempre es posible. Por ejemplo, el caso contrario al ejemplo anterior. En tal caso no habría que reducir sino, ampliar la tabla de colores. Ambos procesos (reducción y ampliación) serán designados aquí genéricamente con el término escalado de colores. Para escalar una tabla de colores, se utiliza un factor de escalado que viene dado por la relación entre el número de colores original y el de destino. La nueva paleta posee los mismos colores que la anterior con la diferencia de que la posición de los triples RGB no es la misma. La nueva posición del color RGB viene dada por el resultado de multiplicar la antigua posición por el factor de escalado. El proceso es el mismo discutido en el escalado del tamaño de las imágenes. Así, si se tiene una paleta de 16 colores y se pretende convertirla a 256, el factor será 256/16 = 16. Los colores originales situados en la paleta de color en las posiciones 0,1,2,3,...,15 se encontrarán en la nueva paleta de 256 colores, después de multiplicarlos por el factor, en las posiciones 0 a 15, 16 a 31, 32 a 47, 48 a 63,...,240 respectivamente. Si se parte de una paleta de 256, el factor es 16/256. Al aplicar el factor, los resultados serán los inversos. Los colores del 0 al 15 serán sustituidos por el 0 en la posición 0, los del 16 al 31 por el 16 en la posición 1, y así sucesivamente. La aplicación de la reducción de colores a una imagen dará resultados insospechados si previamente no se aplicó la ampliación, ya que los colores en una imagen de menos tonalidades no se encuentran dispersos en la paleta. Habría sido más fácil optar por la solución de mantener la posición de los colores en la paleta, dejándolos en las primeras posiciones pero haciéndolo de esta manera, se consigue una distribución del color que se va repitiendo por bloques a lo largo de la paleta, algo que luego será de mucha utilidad si se desea obtener un resultado medianamente aceptable a la hora de convertir las imágenes a blanco y negro (por dithering) como paso previo a la impresión de las imágenes. 7.3 IMPRESION DE IMAGENES. Ya se adelantaron los distintos tipos de impresoras en el apartado 3.1.4. Se procederá ahora a estudiar la manera de imprimir las imágenes en las impresoras EPSON FX80 (o compatibles) y PostScript. 7.3.1 LA IMPRESORA EPSON FX-80. La elección de la impresora EPSON como ejemplo para la impresión de imágenes no es ni mucho menos aleatoria. Esta impresora se ha convertido en estándar dentro de las de su clase. Normalmente las impresoras matriciales poseen un conjunto de códigos de control o secuencias de escape para realizar determinadas operaciones como son la definición del tipo de letra, la calidad de impresión, el modo gráfico, etc. Se denominan secuencias de escape porque comienzan con el carácter ESCAPE (27). Muchas impresoras aceptan los mismos códigos que la impresora EPSON. Por otra parte, lo de menos son las secuencias de escape, lo importante es comprender cómo funciona una impresora matricial en modo gráfico y cual es el método para codificar y enviar la imagen, aspecto común en la mayoría de las impresoras de este tipo. El proceso para transportar la técnica a otra impresora matricial no debe suponer ninguna dificultad más que la de sustituir los códigos (y en ocasiones su orden) por los del nuevo periférico. Se ha mencionado anteriormente la problemática de la impresión de imágenes a color en dispositivos de blanco y negro. Este tema ha sido tratado en el apartado dedicado al dithering. La EPSON FX80 es una impresora de 8 agujas en blanco y negro, por consiguiente, un paso previo a la impresión es la conversión de la imagen a monocromática. La conversión de una imagen de menos de 256 colores a blanco y negro conlleva el paso previo de escalar la imagen a 256 colores, lo que proporciona mejores resultados al aplicar el algoritmo de dithering. El método de dithering usado es el de Floyd-Steinberg. Una vez hecho esto se está en condiciones de enviar la imagen a la impresora. Una línea de datos de una imagen monocroma vista en el monitor consiste en un número de bytes consecutivos en los que cada bit de cada byte controla un pixel. Un byte de una imagen gráfica enviado a una impresora dará como resultado la impresión de 8 pixels en el papel, pero éstos se imprimirán verticalmente. El primer byte enviado a la impresora constituye el primer pixel de las ocho primeras líneas. El siguiente byte serán los segundos pixels de las ocho primeras líneas y así sucesivamente hasta completar el ancho de la imagen. A continuación el siguiente byte se corresponderá con los primeros pixels de las líneas 9 a 16 y así hasta el final. Se requiere una gran cantidad de manipulaciones a nivel de bits para convertir una imagen de mapa de bits y enviarla en el orden correcto a la impresora. Además de esto, deben enviarse códigos de escape. Es preciso indicar a la impresora que no se van a imprimir caracteres, sino gráficos. Cada línea de información gráfica debe ir precedida por una secuencia de escape que dice a la impresora la resolución con la que será impresa la línea y el número de bytes de información a procesar como gráfico (el ancho de la línea). Después de cada línea debe enviarse los códigos para que el papel avance exactamente 8 pixels y el cabezal se sitúe de nuevo al comienzo de la línea. Los códigos más importantes para la impresión de imágenes gráficas en una FX80 son los que inicializan la impresora, los que seleccionan el modo gráfico y los que indican el ancho de la línea a procesar. Para inicializar la impresora se usa la secuencia: ESC @ Las secuencias de escape para los distintos modos gráficos son las siguientes[5]: SECUENCIA ACCION ESC K n1 n2 Densidad normal 60 puntos/pulgada, 640 pixels de ancho máximo ESC L n1 n2 Doble densidad 120 ppp, 1280 pixels máximo ESC Y n1 n2 Doble densidad, alta velocidadIgual al anterior, más rápido ESC Z n1 n2 Cuádruple densidad, 2500 ppp Donde: ESC es el código ESCAPE (27). K, L, Y o Z se envían tal cual. n1, n2 son dos bytes para indicar el ancho de la línea. n1 es el byte menos significativo y n2 el byte más significativo. Otra manera de especificar el modo gráfico es usando la secuencia de escape: ESC * modo n1 n2 En este caso, los modos son los siguientes: CODIGO MODO 00H Densidad normal 01H Doble densidad, baja velocidad 02H Doble densidad, alta velocidad 03H Densidad cuádruple 04H Emulación Epson QX-10 05H Emulación plotter 06H Pixels cuadrados Por último, el avance del papel se consigue con la secuencia: ESC J n Donde n especifica un avance de n/216 pulgadas. El proceso para la impresión de las imágenes es el siguiente: Inicializar impresora PARA cada 8 líneas de la imagen Enviar modo gráfico y ancho de línea Transformar y enviar las líneas Avanzar el papel Inicializar impresora Antes de proceder a enviar un carácter a la impresora, se deberá testar si está o no ocupada. Además debe de ofrecerse la posibilidad de poder abortar el proceso. La impresión directa se realiza usando la interrupción 17H que se encarga de los servicios del puerto de la impresora. Los servicios que proporciona son los siguientes: INT 17,0 Imprimir carácter INT 17,1 Inicializar puerto de impresora INT 17,2 Leer estado del puerto de impresora El registro de estado del puerto se devuelve en el registro AH del procesador. Sus valores son: Bit 0: Time-out Bits 1-2: No usados Bit 3: 1 = error entrada/salida Bit 4: 1 = impresora on-line Bit 5: 1 = Sin papel Bit 6: 1 = reconocimiento Bit 7: 1 = no ocupada 7.3.2 IMPRESORA POSTSCRIPT. Como se ha constatado previamente, el término PostScript denota un lenguaje de descripción de página usado en impresoras láser[1]. PostScript es un lenguaje con notación postfija que incluye primitivas de dibujo, definición de tipos de letra, escalado de imágenes, etc. Además permite el tratamiento de imágenes de mapa de bits. El código Postscript para la impresión de una imagen puede guardarse en un fichero ASCII; con las ventajas que esto conlleva. Puede visualizarse y editarse. Un fichero Postscript que contenga una imagen bitmap tiene en primer lugar una serie de comentarios. Estos comienzan con los caracteres %%. Identifican al fichero Postscript y dan información acerca de las dimensiones de la imagen el autor, etc. A continuación aparecen los parámetros de la imagen y las órdenes para la impresión del bitmap. Esta es la información que se codifica con notación postfija. Tras las instrucciones aparece el bitmap como una serie de valores hexadecimales. Por último, la instrucción para imprimir la imagen: showpage. La aplicación prevé la impresión de imágenes en blanco y negro y a color. Estas últimas deben convertirse a gris. No es objeto de este trabajo explicar la sintaxis y filosofía del PostScript, existen multitud de libros que tratan sobre este potente lenguaje a los que acudir para profundizar en el tema. En la aplicación se ha usado un sencillo método para la impresión, extraído de ficheros de salida postscript de otras aplicaciones. Apendice A: Lista numérica de Tags. TIFF Versión 5.0 TAG (Nombre y número) Tipo Valor por defecto NewSubfileType 254 (FE) LONG 1 SubfileType 255 (FF) SHORT 1 ImageWidth 256 (100) SHORT o LONG 1 ImageLength 257 (101) SHORT o LONG 1 BitsPerSample 258 (102) SHORT SamplesPerPixel Compression 259 (103) SHORT 1 PhotometricInterpretation 262 (106) SHORT 1 Threshholding 263 (107) SHORT 1 CellWidth 264 (108) SHORT 1 CellLength 265 (109) SHORT 1 FillOrder 266 (10A) SHORT 1 DocumentName 269 (10D) ASCII ImageDescription 270 (10E) ASCII Make 271 (10F) ASCII Model 272 (110) ASCII StripOffsets 273 (111) SHORT o LONG StripsPerImage si PlanarConfiguration es 1. SamplesPerPixel * StripsPerImage si PlanarConfiguration es 2. Orientation 274 (112) SHORT 1 SamplesPerPixel 277 (115) SHORT 1 RowsPerStrip 278 (116) SHORT o LONG 1 StripByteCounts 279 (117) LONG o SHORT StripsPerImage si PlanarConfiguration es 1. SamplesPerPixel * StripsPerImage si PlanarConfiguration es 2. MinSampleValue 280 (118) SHORT SamplesPerPixel MaxSampleValue 281 (119) SHORT SamplesPerPixel XResolution 282 (11A) RATIONAL 1 YResolution 283 (11B) RATIONAL 1 PlanarConfiguration 284 (11C) SHORT 1 PageName 285 (11D) ASCII Xposition 286 (11E) RATIONAL YPosition 287 (11F) RATIONAL FreeOffsets 288 (120) LONG FreeByteCounts 289 (121) LONG GrayResponseUnit 290 (122) SHORT 1 GrayResponseCurve 291 (123) SHORT 2**BitsPerSample Group3Options 292 (124) LONG 1 Group4Options 293 (125) LONG 1 ResolutionUnit 296 (128) SHORT 1 0PageNumber 297 (129) SHORT 2 ColorResponseCurves 301 (12D) SHORT 3 * (2**BitsPerSample) Software 305 (131) ASCII DateTime 306 (132) ASCII Artist 315 (13B) ASCII HostComputer 316 (13C) ASCII Predictor 317 (13D) SHORT 1 WhitePoint 318 (13E) RATIONAL 2 PrimaryChromaticities 319 (13F) RATIONAL 6 ColorMap 320 (140) SHORT 3 * (2**BitsPerSample) BIBLIOGRAFIA [1] Bit-Mapped Graphics, 1990. Steve Rimmer. Windcrest Books. [2] Programación en Windows, 1992. Charles Petzold. Anaya Multimedia S.A. [3] TIFF 5.0 An Aldus/Microsoft Technical Memorandum 1988. Aldus Corp./Microsoft Corp. [4] Manual del usuario PM 3580/PM 3585. Philips Corp. [5] Manual de usuario Impresora Amstrad DMP 3000, 1987. Amstrad plc. [6] Guía de referencia para programadores en Informática gráfica. Alfredo Sanz. Fidonet. [7] PC WORLD nº 61 "Formatos gráficos". J. de Iraolagoitia. [8] PC MANIA nº 20 "El formato IMG", 1994. J. Domínguez. [9] PC MANIA nº 23 "El formato GIF (II)", 1994. J. Domínguez. [10] PC MANIA nº 24 "El formato GIF (III)", 1994. J. Domínguez. [11] PC ACTUAL "Formatos gráficos", Julio 1993. Cura/Sanz. [12] Manual de uso Turbo C++ 2.0. Borland International. [13] Manual de uso Turbo Assembler. Borland International. [14] Manual de uso Sistema Operativo DOS. Microsoft Corp. [15] Programación gráfica en C, 1991. Lee Adams. Anaya Multimadia S.A.